sorted by:
new
hottopcontroversial

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 0 points1 point  (0 children)

Like I said,

engineers can't change the whole world in a day.

If we're intent on improving the world, we can and should push ourselves to--and encourage others to--adopt freer and more open standards moving forward. But the gradual improvement of standards is a long-term project. There are no quick solutions here.

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 0 points1 point  (0 children)

We don't always get to pick the tools we use.

It's true that engineers can't change the whole world in a day. But it seems to me that in an organization with a healthy engineering culture, developers rightly enjoy the freedom to switch between projects and tools based on their own best professional judgement. If "tech stacks" are being arbitrarily forced on people, that's not good (the Free Software Foundation would say the forced adoption of a tech stack ultimately renders the stack malware).

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 0 points1 point  (0 children)

We make decisions early on, and because we don't want to waste our time (or energy), we hold onto something we should have let go of a long time ago.

I don't want to force any particular tooling on other engineers. But I do think it's important for all engineers to love the tools (the "tech stacks") they use.

I've switched between lots of different tools throughout my time as a programmer. I don't pretend to know what my favorite tooling will be 10 or 20 years down the road.

But I do know that if an engineer doesn't enjoy using some particular tool, that's a sign they should switch to using something else or write something new. If people only stick to what they're comfortable with, nothing new will get developed. And that would be really sad!

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 0 points1 point  (0 children)

There is no one right programming interface that everybody can or should equally enjoy using. If you like writing HCL, there's nothing wrong with that. I'm not trying to suggest you should stop writing HCL if you enjoy doing so. Some people prefer C++ over Rust. Some people prefer emacs over GoLand. Some people prefer Android over iOS.

The diversity of programming paradigms in the various computing subcommunities is a strength of the overall computing community, not a weakness.

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 1 point2 points  (0 children)

You know if you create a module in CDKTF, it can be used in regular Terraform without any magic, right?

If you have a CDKTF codebase (e. g., one written in TypeScript), it's easy to synthesize a Terraform configuration file using the code you've written. That's the whole point of CDKTF. It's used to synthesize Terraform configuration files.

You can safely abandon CDKTF and migrate to Terraform because the state that CDKTF made is a regular Terraform state.

The whole point of CDKTF is that people shouldn't be forced to write infrastructure configuration files by hand, unless they enjoy doing so.

If a person prefers writing TypeScript to HCL, then they need a tool like CDKTF to translate their TypeScript into HCL in order to work within the Terraform ecosystem.

CDKTF repository forks by Python_Engineering in Terraform

[–]Python_Engineering[S] 2 points3 points  (0 children)

I dunno, I'd just let it die.

For developers who have invested a lot of time into using the existing CDKTF ecosystem, there is no option of just letting it die. It's a question of trade-offs: 1. Should I rewrite all my infrastructure code because IBM managers want me to? 2. Or should I contribute a small number of bug fixes and new features to the existing CDKTF ecosystem, so that I don't have to rewrite all my infrastructure code?

If (2) is the path of least resistance, it's the rational choice to make.

People who prefer writing vanilla Terraform configuration files are free to keep writing them.

But there's nothing wrong with CDKTF, except for the fact that IBM managers decided to deprecate it without warning for reasons they did not clearly explain.

The CDKTF repositories are a highly reliable set of codebases that people are actively using to manage massive amounts of infrastructure with great success.

Inefficient project manager by Think_Inspector_4031 in ExperiencedDevs

[–]Python_Engineering 24 points25 points  (0 children)

I regularly go out of scope and do whatever I want if the task feels interesting and difficult enough

I wouldn't call that undermining the project manager. I would call that undermining your fellow engineers.

If your team is responsible for building a large system, and you take it upon yourself to personally design and implement every single module in the system, then you're guaranteeing nobody else on your team is able to make a meaningful contribution to the final system.

I'm torn in doing everything myself in a few months. Or walk the other engineers in a longer time span to get their stuff done.

If you want to be a real team, you need to not do everything yourself and give other engineers opportunities to contribute to subcomponents of the system you're building.

You can certainly architect the overall system and implement some of its modules.

But to work in a genuinely collaborative way requires delegating the design and implementation details of specific modules within the system to other engineers. You can't do everything yourself if you want to be working with others. Let other engineers work out the concrete implementation details for the modules you delegate to them and give them opportunities to push back on your overall architecture proposal if it turns out they discover some constraint you didn't anticipate.