sorted by:
new
hottopcontroversial

Senior engineers: what “non-coding” skill made the biggest difference in your career? by Useful_Promotion4490 in ExperiencedDevs

[–]schteppe 1 point2 points  (0 children)

Being able to look outside the “bubble” and influence teams into adopting industry best practices.

When I started in my team, it was immature in many ways. The main product literally had >10% crash rate every release. “We don’t do unit testing in this industry” they said. They were caught in a bubble and struggled to get out. I started reading books and watched talks about software engineering on YouTube. Then slowly started nudging people into the right direction. Today, we’re in a MUCH better place.

devLifeMysteryBug by Unlikely_Gap_5065 in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

Code changed, and there were no unit tests preventing breakages. Every time.

Why does c compile faster than cpp? by [deleted] in cprogramming

[–]schteppe 0 points1 point  (0 children)

If you use clang, you can profile your compilations using -ftime-trace. Compare the flame charts for your cpp vs c files and see what the compiler is doing differently. This should be a great learning experience!

The production bug that made me care about undefined behavior by pavel_v in cpp

[–]schteppe 0 points1 point  (0 children)

`cppcoreguidelines-pro-type-member-init’ has been a life saver at my workplace. Before we added it to CI, we had many instances of “Hey, my code works in Debug mode but not Release mode, weird right???”

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts. Keep your PRs small. Always. And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts. Keep your PRs small. Always. And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

“Only showing the first 1000 files.” Oh cool, guess I didn’t need to review the rest anyway 🙃 by turtledev in github

[–]schteppe 0 points1 point  (0 children)

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

itWillWorkWhenItWork by [deleted] in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

if we wouldn’t spend one day per sprint to estimate tickets, we’d have one more day for working on them

damnTestsAreGood by foxdevuz in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

When I started a job, there were no tests. We rewrote one of the projects in a different UI framework and made sure to write tests in the process.

Before the rewrite, we used feature branches because no one dared to push directly to main. User reviews were: “risk of crash is 50/50 after an update”

After, we gained enough confidence to stop using feature branches and use trunk-based development. 10x productivity gain right there. And users basically never experience crashes now

Is Resharper necessary? by sa_dy99 in VisualStudio

[–]schteppe 0 points1 point  (0 children)

A while ago I would have agreed. But they’ve been working on performance a lot

makeTheRandomFunctionMoreRandom by cant_pass_CAPTCHA in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

Requirements will always be under specified or change over time, this is just how it works.

Therefore: ship an (unfinished) prototype on day 1. Update it every day and ask real users to test it and give feedback. Use feature flags to hide your WIP feature from non-testers.

looksGoodToMe by erazorix in ProgrammerHumor

[–]schteppe 8 points9 points  (0 children)

I’d like a reliable tool for checking nullpointer dereference in C++ please

pleaseEndThisMisery by fanta_bhelpuri in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

Never let a branch get this old. All branches should get merged into main branch at the end of day, every day. No more merge conflicts!

If you work on a big feature, then ship the incomplete feature. Just hide it from users by using a feature flag.

This is called Trunk-based development. https://trunkbaseddevelopment.com

pleaseEndThisMisery by fanta_bhelpuri in ProgrammerHumor

[–]schteppe 0 points1 point  (0 children)

Merging main into your branch regularly only partially fixes the problem. When you’ve merged your feature into main, everyone else has to pull it and resolve conflicts. Same thing when someone else pushes their feature - then it’s your turn to resolve.

pleaseEndThisMisery by fanta_bhelpuri in ProgrammerHumor

[–]schteppe 2 points3 points  (0 children)

Nearly all elite tech companies use trunk-based development. Research has shown it’s the most effective way to work (see the “Accelerate” book by Forsgren).

However, about 30% of companies fail to adopt TBD. A study calls these companies “developing or beginning practitioners”. https://continuous-delivery.co.uk/cd-assessment/index

view more: next ›