I am happy, my first open source contribution was merged within 2h without any regressions!!
.
.
.
.
.
.
.
.
Well, it was only a typo in Readme.md which I have fixed 😂

A repressed memory just popped into my head:

At my former job I tried to explain a problem I was having to the tech lead. Then, without fully understanding the problem, he decided to rewrite my code that I had been working on for weeks. His code, that took him 2 days to write, went straight to master without peer review.

He introduced about 10 regressions…

Queue the client meeting where the client says “These bugs came back, and we thought they were fixed already…” (They demo the bugs)

So obviously I say “I’ll let Techlead address that one.”

He just mumbles some stuff, and goes quiet for the rest of the meeting. Finally, when the meeting was wrapping up we hear “It’s Fixed!”

Everyone was like ???

“That bug from earlier, it’s fixed, it should work now….”

Would you believe this guy decided to code during the entire meeting, clearly missing important feedback and information that would help him understand the problem. Again, pushing to master without review….

Not to mention that we were talking about 10 regressions…

Yes, senior developers get stuck just as much as junior developers do, the difference is that they get stuck in places that junior developers can’t even access. That is partially because senior developers are expected to do so much more than just simple coding, they need to also grasp and untangle client requirements, communicate clearly and thoughtfully with the team, be some sort of guiding/mentoring/leading figure, make sweeping architectural decisions, and so on and so forth.

A junior developer is struggling with making relevant columns of a table a nice shade of purple. A senior developer is struggling with making sure that implementing new client requirements will not have a destructive impact on the current infrastructure, there will be no regressions elsewhere in the system, tries to pinpoint what prior assumptions the new stuff breaks (it inevitably does), and how to reconcile everything.

During a company wide status meeting where all product managers, architects and directors assemble:

Me: *A product architect leading a team of devs*

Directors: So are there any issues or risks you see in delivering the next build in target time for Client 1?

Me: There are too many changes in feature requirements. First they said we can use a shared NFS for storage. Now they are asking to switch over to SFTP pull mode.. blah blah..

Directors: Oh I see.. well we can support both solutions then.

Me: But the deadlin..

Directors: *ignores what I say* Will be a good marketing point for future.

Me: But there are too many regressions in integra..

Directors: *ignores what I say* We should also meet deadlines. That is the most important thing.

Me: Its not as easy as 1+1=2.. The team needs more time to..

Directors: *ignores what I say* Ok lets move on to the next point. What about Client 2?

Me:

"LeT's uSe gRaPhQL!" They said.

"It EliMinAtEs cOmpLeX aNd vErBoSe REST coDe!" they said.

Me sitting here for hours waiting for the backend team to fix major regressions every time they push the smallest "updates" to staging... 🤡

Call me a boomer but I can't help but feeling graphQL makes things MORE complex than REST... either that or the backend devs have no idea what they are doing

"Older versions are more stable"

The whole concept of LTS in development pisses me off.

Delayed upgrading, whether it's the language itself, dependencies or tooling, does just one thing: It makes future upgrading way more difficult, often to the point where the company eventually runs into this maintainability wall, and gets stuck in old, unsupported versions.

"But... stability!" — The tiny chance that the newer version has such serious stability regressions that it negatively impacts your own product doesn't weigh up against the clusterfuck you fall into if you push the task too far into the future.

You can relatively easily assess a new major language version using benchmarks and unit tests. Predicting the repercussions of staying on PHP 5.4 or Python 2.7 for another year, predicting the impact of upgrading the codebase later, that is almost impossible.

I'm not saying you should live on the bleeding edge in production, but as soon as a new stable version of a core technology is released, just fucking drop everything you're doing and port those deprecated methods!

I think I'm falling in love. With TDD.

I used to be very skeptic about it. You know, the usual reasons: it takes longer to deliver, constant "flow" interruptions, etc, etc. But ever since I've tried it I'm nothing but happy about my choice :)

I'm moving forward, I'm not making any regressions, I'm no longer afraid to make any changes in my code as I know tests will show what exactly I break,.. And most importanty, I have all use-cases with corner-cases defined and "explained" in the code... No more do I have to search in Confluence for how this exact scenario should behave. Everything is here. Everything's in the tests.

It's amazing!

Yeah, it DOES take longer to deliver so if you're hardcore Agile living by "Ship it as soon as it compiles" TDD might be too slow. But if you prefer knowing when your code is covering all the use cases w/o any errors -- TDD is the way.

Days since last issue from 3rd party library: 0

It doesn't get any better than this folks!

It just makes me even more joyful to know that said companies library earns them 1000x figures of what my company earns! Yay software!

Product manager: When building new features, we find we have bugs that reappear in other parts of the app where the bug was solved before. We have to find a solution to this issue.

Dev: These are called regressions, they happen all the time in software development.

Product manager: ...

Dev: Fuck outta here! Its friday!

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.

Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).

They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.

After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.

I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.

I'll do the tests later on it'll be fine. 3 releases on, There are bugs everywhere - I cannot handle the regressions. Why'd this happen..Yeah.. Really need to do some proper TDD at some point.

Been stuck a week with JSON serializer struggles on the backend I'm working on... First of all, this project has source code dating back to 2013, and the dudes back then decided to use three versions of json. So you have your usual application/json and then two custom ones.

Not happy with that, they decide on using two serializers, XStream and Jackson. One custom and application/json run through XStream, and the other more legacy custom JSON runs through Jackson. So this is a bloody mess.

But now they want application/json running through Jackson, and this is breaking all the regression tests. Have to reimplement all the type, field, alias and other kinds of mappings they made for XStream, and sort out all the regressions this causes.

And the dude who designed all of this is revered in the company, although he left a while back. Not sure if I'm too much of an idiot to understand the utter brilliance of the approach, or its just poorly designed... Fuck my life, those due dates just keep creeping closer and closer and this kinda crap just keeps coming :S

WHAT GOES AROUND COMES BACK AROUND

Overflooded with tickets about regressions, management finally gave in and instructed us to use integration tests again.

Who would have seen that one coming.

(at least half of these "regression tickets" were not regressions at all, but I'm not going to be the one spoiling the first time management actually makes the right call)

Fellow Ansible developers. I'm talking to you.
Are you freaking high or simply your morning pills have some serious side effects?
How do you manage to introduce a number of regressions in every fucking major release? How on earth you feel comfortable in breaking API in a minor and even bug fix releases?
You need to get me right. I really like Ansible project but those things... I imaging you every other day as a bunch of hamsters trying to find an exit in a shitty labyrinth which you call the codebase.
If you will not stop to eat and smoke those things this would became a lot worse indeed.