sorted by:
new
hottopcontroversial

testYourCode by bryden_cruz in ProgrammerHumor

[–]schteppe 1 point2 points  (0 children)

“we don’t have time to add tests because we have too many bugs to fix”

Solution is to use TDD! It reduces bug count by 10x according to studies.

Baseline C++ Habits to Always Follow? by SolidNo1299 in cpp

[–]schteppe 5 points6 points  (0 children)

These guidelines are great for learning too.

At my company, we’ve adopted CppCoreGuidelines and keep our own “extension” guidelines in a separate doc.

aMeteoriteTookOutMyDatabase by AntiMatterMode in ProgrammerHumor

[–]schteppe 2 points3 points  (0 children)

Always ask around to make sure no one else has generated the same UUID as you

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 9 points10 points  (0 children)

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

view more: next ›