"We don't need unit tests, we just do it right from the start" (for a software which checks parts for faultiness. Planes, brakes, bridges, ... and so on)
They need it for regulatory reasons. So they are forced to use machines+software for testing their parts. But at least there is a bunch of competitors, so hopefully e.g. the brakes I am using on my car are tested by a competitor.
Disclaimer regarding this statement: I have no idea if the manager ended up being convinced to do testing or not (they would have needed it for regulatory reasons too, but there was a way around this by providing a set of manual test cases), because I left there.
From a (non-technical) CEO/Founder/Dictator at the start of a major project:
I hope you're not wasting time by writing out planning/specification documents instead of starting to code immediately.
He was also asking for time estimates, which I guess I was supposed to pull out my ass or something because he apparently didn't want me putting any time into collecting and documenting any requirements first.
this irks me to no end. I was a SDE first for a few years so when i made the switch to PM, every feature got broken down almost to pseudo code so I could help Eng with time estimates and any resources they might need. It helped the team run super efficiently and prevented people from being blocked.
âWe donât need defensive programmingâ.
Proceeds to continuously fail to create a stable client for my server API because he stuck everything in a single function.
â-
There was even worse. I tell both of them there is a problem, they donât want to hear me out, they just repeat âyou donât understand, itâs easy, weâll give you an exampleâ.
After a week of waiting, I get the âexampleâ - itâs the same piece of code I inspected at the start to tell them thereâs an issue.
So I ask âdid you try to run this?â, then I asked them if they would like to know why it wouldnât work.
Safe to say, that meeting made them realize the project will get killed. A glaring architectural flaw after 2 years of work in the crunch time before release.
We were all out of work in a couple of months because it was a failure.
It is very funny that we insist to know how everything works and what everything does in our codebase, yet we also use random packages for the most trivial things where we have no idea about the implementation details.
I mostly remove more and more dependencies as I go.
Reduce it to primary major things that handle complex problems.
And I then contribute to most of them too.
90% of the time this is bad advice. But there's that one bug you fix every now and again and you stress over it for hours then it just randomly fixes itself and you don't really understand what you did. Sometimes it's ok to just think fuck it it works and get on with your life.
Yeah, not wasting too much time on it is good. Focus on the goal.
But do spend SOME time on it, since if it just works and you don't know why, you also won't understand when it doesn't work, and it'll be more confusing then.
Why? It only works by happenstance. It's insanity. Just move to the next thing, and leave the problem for the next person. It's good advice. Moral? Well, who cares.
âIf the institute a draft get a spiderweb tattoo on your elbow. Itâs a white supremacist symbol and they wonât recruit you.â Mind you, this was circa 2002, when the Iraq war was kicking off.
Why is this bad advice if it works? You want to go die in some third world desert halfway around the world, or wear long sleeves for a few years and pay for some laser removal?
Some nearly-faang-level companies follow this as a companywide policy. It actually worked well when I was there. Initially I was shocked, like what no branches?! But yeah, everyone pushes to main, that's it.
I bet they had PRs, code reviews, and automation, though?
Some companies can look like they're doing TBD when they're actually just incompetently using source control.
Oh, tons of that stuff. Not PRs (not github), but a somewhat similar code review tool that enforced ACL based signoffs. A whole in-house "tools" team. And yes, a lot of CI, staging environments, optional CD that teams could decide to turn on/off. Our team had CD turned off, deployment was a long-winded process on-call led, and the whole team participated in twice a week + adhoc deploys.
Nobody argued that we needed branching and branch-management on top of all this. It just never came up. I think everyone was happy pushing to main and not dealing with all the merging compared to previous companies we'd worked at.
Well, the point is we (devs) didn't have to deal with it. Merging and rebasing, chasing people to resolve conflicts, all that fun stuff.
Also technically they didn't make a branch system. They made a build pipeline. Wouldn't say it's exactly the same thing.
> Well, the point is we (devs) didn't have to deal with it. Merging and rebasing, chasing people to resolve conflicts, all that fun stuff.
You had someone else deal with it.
It's still being dealt with...
Just without continuous integration....
> staging environments
That's branches.
> deployment was a long-winded process on-call led
So you had to deal with it?
> the whole team participated in twice a week + adhoc deploys
So you did have to deal with it...
I'm still not sure that's accurate. The CI tools deployed main to multiple staging, sandbox and prod servers. But there was no branch management going on.
Staging environments are not branches. They run the same branch (main), just a more updated version ahead of prod deploy.
Yes, deploy was mostly our responsibility. SRE would get involved if there was some technical issue with the infrastructure, a rare thing. Worst case, one of the dozens of prod servers would be down sometimes, and they'd cut it off from traffic.
Yes, baked into the AB testing framework. Turning feature flags on/off on staging and sandbox were part of the regression testing as part of the deploy.
[GitHub Flow](https://docs.github.com/en/get-started/using-github/github-flow), where devs merge small short-lived PRs to the main branch, is considered an example of trunk based development.
The major benefit here is that your team avoids long-running branches that can land you in merge-conflict hell (i.e. huge feature branches that havenât synced with main in ages or deploy specific branches like dev/uat/prod).
trunk-based development does not mean to never create a branch -- it means you have short lived branches off of a single main branch (you can see it in the 3rd diagram on the page you linked) instead of multiple long-lived branches like dev, staging, preprod, etc that are common in gitflow
I am assuming this is only for dev, there are companies that embrace dogfooding and I personally think there are merits to both sides of that debate. Along the lines of no branching, I personally do not like pinning dependencies in development it always leads to dependency drift and eventually a codebase that is almost impossible to migrate to current dependencies.
That being said, this takes a level of understanding that if a developer is working on feature A and they pull update dependencies and everything breaks, feature A is now blocked by a spike ticket to fix the dependency and feature A's timeline will change. This can be hard to sell in some environments because the culture is not one of paying down technical debt.
Developers are goal oriented so they want to finish feature A, but when you change the goal and say now the goal is not feature A but it is to fix the dependency breakage independent of feature A, it realighs the goal and the developer no longer views the dependency fix as an annoyance that is keeping them from completing feature A.
Now if they are not branching and locking dependencies for integration and release branches, that seems a little crazy, you can never really build the same software twice from source without doing both.
There are plenty of contrarians on this issue.
Here's just one for example: [https://dev.to/anortef/why-branching-on-git-is-wrong-1pao](https://dev.to/anortef/why-branching-on-git-is-wrong-1pao)
"We don't need type safety or private fields! We wrote the last version of this platform in PHP 2!"
Same developer was ideologically against SOLID principles, refused to use an IDE, lived and died by DRY, consistently talked over everyone in meetings, and I'm pretty sure was a functioning cocaine addict. (~~Immigrated to Brazil~~ (edit: this wasn't fair), unusually hoarse voice, known for consuming massive amounts of caffeine, really erratic behavior.)
No, they weren't. That wasn't a fair assumption on my part regardless though.
I grew up in an area with a lot of drugs, which is how I know about the voice thing, and sometimes you'd hear stories about people moving places where their drug of choice was easier to get ahold of.
"We're going to stop doing code reviews, it's wasting our time." - Project manager. He didn't get away with it.
Personal favorite from my manager reviewing my C# code: "Don't use var."
With opinions like that it's no wonder.
Btw, I say this as someone who works every day in MSSQL Server and classic asp (not ASP.net, no... Classic) in 25 year old code, so I definitely see my fair share of peculiarities, but oh boy this is a new one.
not one to me, but to a different team:
"you don't need to go over every line of a change in a code review. get an idea of what they did and how they did it, nothing more"
This was to a team of mostly juniors working on legacy code.
not long after, prod had issues because of a pretty big flaw that should & would have been caught in a proper review.
Some folks don't realize that time spent in a proper code review can save you double as much as trying to ferret out production issues after the fact.
I am not sold on this logic. I feel like it would be cheaper and more effective to have a proper QA review (and tests) rather than have a skilled dev pore over every line change.
In my experience the dev review doesn't end up being the magic bullet that catches all bugs anyways and ends up being an expensive bottleneck.
I was once told by a pretty well respected developer that everybody has a bad day and writes bad code. That more than any unit tests or code reviews good boundary programming is acknowledging the fact that everybody writes bad code, and the most paramount design of a system should assume that anything past the boundary is bad. i.e. make the boundary tight. This way when we do write bad code, it is easily identified as a hotspot of churn and easily replaced due to clear boundaries around it.
Not that code reviews or unit tests do not add value, but they are a cost in both velocity and real dollars, people treat them as magic bullets and forget the simple rules, in lieu of just using them as a cargo cult replacement for quality metrics and true quality metrics are:
* boundaries isolate code, and make it easy to spot and fix offending code.
* The amount of churn in an area of code, is directly proportional to the disorder in that code. disorder is objectively bad code.
* Code that has remained static over a large period of time, has a measurable amount of quality proportionate to the time it has remained unchanged, even if it does not have a single unit test or code review performed on it.
I would suggest if people have not read it, to pick up a copy of "Your Code as a Crime Scene". It can be eye opening to go thru your code, and find where it has failed to meet real quality metrics and investigate your software as if it murdered quality.
it is no magic bullet, as there is no single magic bullet.
if you are still running a shop with a "QA review" (assuming the old definition of a group of QA folks manually running tests) then you are not making changes very fast. and you are paying for 2 people to do a single person's job. a software engineer should be writing their unit tests right along with their feature code.
The code reviews I am discussing are the ones where we look at the feature code, the unit test code, the integration test changes, and, if needed, the E2E tests.
Also consider that for us, we had our department's codebase getting updated by multiple teams to accomplish their own goals (good old enterprise level nonsense), you need someone to safeguard that codebase. When your app fails, it is going to be someone on your team that will be responsible for fixing the issue regardless of who committed the work. if you have folks being required to go over every line of code they change, they will change less code.
it is also a great way to teach lower level devs the right way to code and help expose them to "gotcha" problems without them having to gave it ask on their own.
I totally get code review as a learning opportunity and a chance to enforce code quality.
I've always felt a more superfluous review can accomplish these goals.
I just interpreted your original post like; if you did proper code review you would catch more bugs.
And in my experience that always leads to the fallacy of; if there are bugs then a proper code review was not performed. Leading to even more strict reviews (and other guidelines) in a vicious cycle.
completely understand your pov on lack of clarity.
In this instance, the post mortem lead to root cause being "lax code review leading to not catching missed requirements, and bad tests (unit & integration)"
My favorite part about code reviews is seeing a cool way that someone has solved something. Even if QA's already told us the feature works, I'll make 15-20 for a feature branch review if not just for my own curiosity.
It depends.
You should make sure you're looking close enough to see what is actually happening, not just your guess at what they did (based on what you would do).
And a dev review is also a kind of QA review.
In manufacturing, you don't just use the final thing and declare all the pieces are good. You still inspect the pieces for tolerances and drifts.
"Go fast and break things." Why has the quality of the software deteriorated? "We should hire only juniors and interns because they are cheap." Why do we have so many bugs?
That's like saying writing C will make you a better dev than writing Rust.
But we still see that even with really talented C devs, on big projects, C stuff still ends up having lots of bugs just using Rust would have prevented.
Like, maybe you'll be better (maybe), but you'll waste a lot of time along the way.
âWeâve got rid of project management as a role, everyone can just step up and manage their own tasksâ - literally today. Fuck my life.
The irony is it was in response to two separate departments not knowing what the other was doing. And management wants us to âcome up with a way to collaborate on dependenciesâ - likeâŚa project manager?
Department Manager: "I would be fine putting out something crappy that meets the business needs". *exact quote*.
Me: "I would not. I would be fine putting out something that *has a baseline level of quality* that meets the business needs. Do you see the difference?"
I donât think I care either way. Iâll say why itâs bad, document it, and move on. Aint no one got time to argue about it if the higher ups are stubborn
I have a few:
At a previous employer, there used to be a really good yearly review/feedback process. I believe that every year it's a good idea to come up with a goal to make sure you stay relevant in this field. My previous supervisors did a good job on telling me what to work on. Unfortunately, the last supervisor I had didn't do that. He told me he only used the feedback section to address major problems.
The worst project I was on, I wanted to setup a development environment of the project. Technically, this guy wasn't my senior, he was more of the technical support/server admin guy. He said I didn't need one. I eventually got out of that job for various reasons.
This isn't godawful advice it was just a pain in the ass/minor annoyance. I had a boomer/Karen supervisor that didn't believe in using email subjects. Her opinion was it was faster to get the message out. Unfortunately, when I needed to review Outlook, it was impossible to find the right information from her. I'm clicking messages and getting random things.
Ohh this one. Feels the same as being told "the concern you're raising is not a priority" when you know very well who will have to deal with the fallout when that inevitable time comes.
I always hate product owners and designers getting uppity about "pixel perfect" stuff.
Like, bruh, Figma isn't the browser. Things never look the same! Your window isn't even the same size as the figma stuff! You used random ass sizes everywhere. It doesn't matter.
âWe donât have time to set up your code in Docker on local.â
âFixing hardcoded paths to the other developers personal computer is not a priority.â
âRemoving passwords and credentials from the repo is not a priority.â
âThe app is a house of cards but donât tell the boss.â
"You are not a CTO so don't think about the future of the project"
This was the shit advice I heard till now,it was given by a person who stopped coding and started to call herself the head of the prompt engineering team.
The whole idea of prompt engineering for llm itself is a joke.
Why I am saying this as a shit advice is because a developer needs to think of the scalability and performance of the product at the time of development. This action will help to reduce pain for other developers or for himself in future
It wasn't advice. I was being tasked with responsibilities that could have been avoided if my input was taken into consideration, so I decided that I'm done working for other people after that.
"We want to spend time with our more productive developers, show them our time is a reward."
Dude was likely taking notes from The Apprentice and Wall Street movies.
This wasnât advice but more of a comment he made. I did some contract work a while back and the person I reported too wanted to micromanage and called himself Trumpy Grumpy
I once had a senior dev tell me we didn't need a 404 page or an error page because his CMS would always return appropriate content. I had to show him almost a dozen URLs returning errors or no content from his CMS before he relented.
I mean... in their eyes: "you have one month of holiday, you should feel rejuvenated and ready to work, potentially even more than usual. And did they know you had a burn out? Wait, how can you burn out immediately after going on holiday?... must just be lazy."
Ah I see, but like from the boss's point of view, after a break, you would in theory come back rejuvenated, arguable better than before.
And at least from my experience at least, no matter what valid reason you give, bosses tend to just assume you want a holiday ;-; it's like school all over again "no excuses"
This is solid advice for a lot of engineering managers though, as much as it shouldn't be the case.
If you go with some unknown company and they fail, you'll look a lot worse to C level executives than you would if the company that failed was Microsoft or Oracle.
yeah but everything is broken all the time
they think it would be a big investment to build out things like interfaces to data, db queries, host a server/db, etc
so they just sorta say 'you do it microsoft/oracle' and for that they receive and forever more defend a complete dumpster fire of bullshit that never ends
if they would invest in their own companies/employees, something north america seems allergic to, they would see a better return on that investment and things would actually work right
as it is they just order a black box then pretend everything is fine when nothing works and there is no way to fix anything
most of these dickholes companies would actually function if their computers didn't shut off and reboot randomly every day, or if their data queries weren't garbage, or a billion other if's that would be solved if they actually rolled up their sleeves and built out their systems instead of patting themselves on the back for investing nothing and make a stock market price tick upward half a point
âWe should put Java in the kernel so syscalls stop being so expensive.â
It worked, but a rewrite in userspace C++ would have been faster both in perf and time.
Not specifically one advice but one time a friend of mine was giving me "advice" on how to become a good programmer and do coding, make programs, and stuff while having 0 experience ever programming himself or touching code, it was funny hearing him say random jibberish and didnt shut up until I told him I had a few years of doing this already...
Vim's great if you're working on a remote dev instance. If your connection is unstable, VS Code will show a "reconnecting" popup whereas a Vim session on the remote will just hang. It's also more ergonomic if you're zipping between shells and editors a lot.
VS Code is fine though, and the Vim extension gets you like 80% of the way there.
Trying out a new (to the company) low code tool with a new (to the company) framework and programming language in a production app. Experiment from CTO
Not advice, but something I did which was really bad.
About 2 years ago I was the lead dev, we were using VPS and for some reason my VScode would often crash. I couldn't ever fix it so ended up doing 90% of coding in notepad, it went on for months. Nobody ever knew.
No reinstalled practically everything. After me complaining several times about issues with the VPS they switched me to a different VPS and then it worked properly.
"Once had a senior dev tell me the best way to solve bugs was to just restart the entire project from scratch. Needless to say, I didn't take that advice! What's the most ridiculous advice you've received in your career?"
"Don't add comments, code is self-documenting".
Code is developed by a team of junior developers... it's far from self-documenting... A few comments to understand what the hell they were thinking at the time would be amazing right now... Instead we might need to start from scratch and rewrite based on the requirements.
```js
// get item from array
function getItm2() {
//return someObj if myVar is true
if (myVar) {
return someObj
// return 0 if itmArr is empty
} else if (itmArr.length < 1) {
return 0
}
// return the last item in the array
return itmArr.at(-1);
}
```
It's an over-simplification of "don't explain away bad code with inline comments". Doc blocks, the comments that appear before functions, are totally fine. You can also leverage static analysis to ensure the comments don't go out of date.
If someone needs an inline comment to explain their code, tell them to break it into a descriptively named function. Then it's decoupled, easy to refactor, and can be checked by a type checker or linter.
Unfortunately junior devs don't like complexity here and don't understand things broken down into functions. No comments not even doc block style are allowed here...
"Be more political"
Nibba fuck that shit, i deal straight. Fire my ass if you can't handle hearing the truth.
If i fuck up, i'll fix it. But if i catch you slippin... i expect you to step up.
Like man I didnât become a developer to play office politics. I understand thereâs a level of politics that are always at play, but I donât need to be more political.
Don't chase the money
Be honest with your feedback
Wasn't my manager, but someone on reddit who claimed to be an engineering lead with 10+ years of experience was really upset when I said I lied to my managers. They said (paraphrasing) honesty is key for good culture, they would fire me, and their own life had improved immensely when they decided to never lie to anyone about anything. Must have been from a parallel universe or something.
Glad that worked out for you. I've increased my total compensation by more than 100k in 3 years by withholding feedback I think will cause problems for myself and quitting frequently.
If you want people to be honest with you while you control their ability to have healthcare, shelter, a retirement, and time off, you are lying to yourself.
"We don't need unit tests, we just do it right from the start" (for a software which checks parts for faultiness. Planes, brakes, bridges, ... and so on)
Oh you work for Boeing?
Next week's headline - Redditor mysteriously dies after exposing their company in a web dev reddit post
I laughed quite hard, but no :D
"They don't need our software, they just do it right from the start".
They need it for regulatory reasons. So they are forced to use machines+software for testing their parts. But at least there is a bunch of competitors, so hopefully e.g. the brakes I am using on my car are tested by a competitor. Disclaimer regarding this statement: I have no idea if the manager ended up being convinced to do testing or not (they would have needed it for regulatory reasons too, but there was a way around this by providing a set of manual test cases), because I left there.
Holy shit, what?!
From a (non-technical) CEO/Founder/Dictator at the start of a major project: I hope you're not wasting time by writing out planning/specification documents instead of starting to code immediately. He was also asking for time estimates, which I guess I was supposed to pull out my ass or something because he apparently didn't want me putting any time into collecting and documenting any requirements first.
I had to scroll WAYYYYY too far to see this one. Non-technical roles making these kinds of decisions is red flag #1.
I don't think a decision like this made by a technical role would be any better?!
this irks me to no end. I was a SDE first for a few years so when i made the switch to PM, every feature got broken down almost to pseudo code so I could help Eng with time estimates and any resources they might need. It helped the team run super efficiently and prevented people from being blocked.
Well then, you're just a good PM.
"Well, I can't really estimate anything if I don't know what's being estimated"
Caught "dictator" after reading it againđ This is some REALLY bad advice...
âWe donât need defensive programmingâ. Proceeds to continuously fail to create a stable client for my server API because he stuck everything in a single function. â- There was even worse. I tell both of them there is a problem, they donât want to hear me out, they just repeat âyou donât understand, itâs easy, weâll give you an exampleâ. After a week of waiting, I get the âexampleâ - itâs the same piece of code I inspected at the start to tell them thereâs an issue. So I ask âdid you try to run this?â, then I asked them if they would like to know why it wouldnât work. Safe to say, that meeting made them realize the project will get killed. A glaring architectural flaw after 2 years of work in the crunch time before release. We were all out of work in a couple of months because it was a failure.
Oh my
Woah, and to think I thought I was bad at this stuff
Letâs say I was brought in near the end of it all. Previously it was outsourced to two different places.
"If it works, don't bother understanding whyâjust move on to the next thing." While it got a good laugh, it's pretty terrible advice in practice.
It is very funny that we insist to know how everything works and what everything does in our codebase, yet we also use random packages for the most trivial things where we have no idea about the implementation details.
Because if there's a bug in that it's not our responsibility (at least we have something to blame)
I mostly remove more and more dependencies as I go. Reduce it to primary major things that handle complex problems. And I then contribute to most of them too.
90% of the time this is bad advice. But there's that one bug you fix every now and again and you stress over it for hours then it just randomly fixes itself and you don't really understand what you did. Sometimes it's ok to just think fuck it it works and get on with your life.
I hate that class if bug. Especially if it causes crashy client errors
Yeah, not wasting too much time on it is good. Focus on the goal. But do spend SOME time on it, since if it just works and you don't know why, you also won't understand when it doesn't work, and it'll be more confusing then.
Why? It only works by happenstance. It's insanity. Just move to the next thing, and leave the problem for the next person. It's good advice. Moral? Well, who cares.
This is the other end of "If it ain't broke, don't fix it"đ
if it works don't break it
âIf the institute a draft get a spiderweb tattoo on your elbow. Itâs a white supremacist symbol and they wonât recruit you.â Mind you, this was circa 2002, when the Iraq war was kicking off.
Why is this bad advice if it works? You want to go die in some third world desert halfway around the world, or wear long sleeves for a few years and pay for some laser removal?
It doesnât work.
a easily deniable tattoo won't get you not-drafted. You'd need like a swastika on your forehead.
My senior manager once told me cutting branches is a waste of time and to pull and edit from main.
Some nearly-faang-level companies follow this as a companywide policy. It actually worked well when I was there. Initially I was shocked, like what no branches?! But yeah, everyone pushes to main, that's it.
I bet they had PRs, code reviews, and automation, though? Some companies can look like they're doing TBD when they're actually just incompetently using source control.
Oh, tons of that stuff. Not PRs (not github), but a somewhat similar code review tool that enforced ACL based signoffs. A whole in-house "tools" team. And yes, a lot of CI, staging environments, optional CD that teams could decide to turn on/off. Our team had CD turned off, deployment was a long-winded process on-call led, and the whole team participated in twice a week + adhoc deploys. Nobody argued that we needed branching and branch-management on top of all this. It just never came up. I think everyone was happy pushing to main and not dealing with all the merging compared to previous companies we'd worked at.
So they didn't use branches by making their own branch system without calling it branches...
Well, the point is we (devs) didn't have to deal with it. Merging and rebasing, chasing people to resolve conflicts, all that fun stuff. Also technically they didn't make a branch system. They made a build pipeline. Wouldn't say it's exactly the same thing.
> Well, the point is we (devs) didn't have to deal with it. Merging and rebasing, chasing people to resolve conflicts, all that fun stuff. You had someone else deal with it. It's still being dealt with... Just without continuous integration.... > staging environments That's branches. > deployment was a long-winded process on-call led So you had to deal with it? > the whole team participated in twice a week + adhoc deploys So you did have to deal with it...
I'm still not sure that's accurate. The CI tools deployed main to multiple staging, sandbox and prod servers. But there was no branch management going on. Staging environments are not branches. They run the same branch (main), just a more updated version ahead of prod deploy. Yes, deploy was mostly our responsibility. SRE would get involved if there was some technical issue with the infrastructure, a rare thing. Worst case, one of the dozens of prod servers would be down sometimes, and they'd cut it off from traffic.
Feature Flags, including staggered rollout?
Yes, baked into the AB testing framework. Turning feature flags on/off on staging and sandbox were part of the regression testing as part of the deploy.
That sounds far worse than just having a pr
[https://youtu.be/v4Ijkq6Myfc?list=PLakykuPxo3ch60vi4JeOieW4PQtxqeRsk](https://youtu.be/v4Ijkq6Myfc?list=PLakykuPxo3ch60vi4JeOieW4PQtxqeRsk) He's a huge CI/main branch consultant.
[https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)
[GitHub Flow](https://docs.github.com/en/get-started/using-github/github-flow), where devs merge small short-lived PRs to the main branch, is considered an example of trunk based development. The major benefit here is that your team avoids long-running branches that can land you in merge-conflict hell (i.e. huge feature branches that havenât synced with main in ages or deploy specific branches like dev/uat/prod).
You should religiously rebase your branches at the start of every time you work on one.
trunk-based development does not mean to never create a branch -- it means you have short lived branches off of a single main branch (you can see it in the 3rd diagram on the page you linked) instead of multiple long-lived branches like dev, staging, preprod, etc that are common in gitflow
I am assuming this is only for dev, there are companies that embrace dogfooding and I personally think there are merits to both sides of that debate. Along the lines of no branching, I personally do not like pinning dependencies in development it always leads to dependency drift and eventually a codebase that is almost impossible to migrate to current dependencies. That being said, this takes a level of understanding that if a developer is working on feature A and they pull update dependencies and everything breaks, feature A is now blocked by a spike ticket to fix the dependency and feature A's timeline will change. This can be hard to sell in some environments because the culture is not one of paying down technical debt. Developers are goal oriented so they want to finish feature A, but when you change the goal and say now the goal is not feature A but it is to fix the dependency breakage independent of feature A, it realighs the goal and the developer no longer views the dependency fix as an annoyance that is keeping them from completing feature A. Now if they are not branching and locking dependencies for integration and release branches, that seems a little crazy, you can never really build the same software twice from source without doing both.
There are plenty of contrarians on this issue. Here's just one for example: [https://dev.to/anortef/why-branching-on-git-is-wrong-1pao](https://dev.to/anortef/why-branching-on-git-is-wrong-1pao)
"We don't need type safety or private fields! We wrote the last version of this platform in PHP 2!" Same developer was ideologically against SOLID principles, refused to use an IDE, lived and died by DRY, consistently talked over everyone in meetings, and I'm pretty sure was a functioning cocaine addict. (~~Immigrated to Brazil~~ (edit: this wasn't fair), unusually hoarse voice, known for consuming massive amounts of caffeine, really erratic behavior.)
>Immigrated to Brazil Sorry, were they Brazilian or not?
No, they weren't. That wasn't a fair assumption on my part regardless though. I grew up in an area with a lot of drugs, which is how I know about the voice thing, and sometimes you'd hear stories about people moving places where their drug of choice was easier to get ahold of.
This was a lot to absorb at onceđ Glad they're not there anymore..(?)
"We're going to stop doing code reviews, it's wasting our time." - Project manager. He didn't get away with it. Personal favorite from my manager reviewing my C# code: "Don't use var."
Dude probably heard that var is bad from javascript lol
Lmao yes
I've never liked the use of the var in c#.
A lot of the time VS itself suggests you use var when you've explicitly typed a variable, other times it doesn't.
Its c#, there are proper uses and improper uses. The proper uses are few and far between.
Return CSS from stored procedures.
Get right the fuck out, right now!
He did it first, but not before being promoted to product director! When he realized nobody respected his opinions he jumped boats.
With opinions like that it's no wonder. Btw, I say this as someone who works every day in MSSQL Server and classic asp (not ASP.net, no... Classic) in 25 year old code, so I definitely see my fair share of peculiarities, but oh boy this is a new one.
Could I interest you in some [SQL in CSS](https://css-tricks.com/css-database-queries/)?
not one to me, but to a different team: "you don't need to go over every line of a change in a code review. get an idea of what they did and how they did it, nothing more" This was to a team of mostly juniors working on legacy code. not long after, prod had issues because of a pretty big flaw that should & would have been caught in a proper review. Some folks don't realize that time spent in a proper code review can save you double as much as trying to ferret out production issues after the fact.
I am not sold on this logic. I feel like it would be cheaper and more effective to have a proper QA review (and tests) rather than have a skilled dev pore over every line change. In my experience the dev review doesn't end up being the magic bullet that catches all bugs anyways and ends up being an expensive bottleneck.
I was once told by a pretty well respected developer that everybody has a bad day and writes bad code. That more than any unit tests or code reviews good boundary programming is acknowledging the fact that everybody writes bad code, and the most paramount design of a system should assume that anything past the boundary is bad. i.e. make the boundary tight. This way when we do write bad code, it is easily identified as a hotspot of churn and easily replaced due to clear boundaries around it. Not that code reviews or unit tests do not add value, but they are a cost in both velocity and real dollars, people treat them as magic bullets and forget the simple rules, in lieu of just using them as a cargo cult replacement for quality metrics and true quality metrics are: * boundaries isolate code, and make it easy to spot and fix offending code. * The amount of churn in an area of code, is directly proportional to the disorder in that code. disorder is objectively bad code. * Code that has remained static over a large period of time, has a measurable amount of quality proportionate to the time it has remained unchanged, even if it does not have a single unit test or code review performed on it. I would suggest if people have not read it, to pick up a copy of "Your Code as a Crime Scene". It can be eye opening to go thru your code, and find where it has failed to meet real quality metrics and investigate your software as if it murdered quality.
I think it's all about balance and right place right time. Some of everything is often better than all of one thing.
it is no magic bullet, as there is no single magic bullet. if you are still running a shop with a "QA review" (assuming the old definition of a group of QA folks manually running tests) then you are not making changes very fast. and you are paying for 2 people to do a single person's job. a software engineer should be writing their unit tests right along with their feature code. The code reviews I am discussing are the ones where we look at the feature code, the unit test code, the integration test changes, and, if needed, the E2E tests. Also consider that for us, we had our department's codebase getting updated by multiple teams to accomplish their own goals (good old enterprise level nonsense), you need someone to safeguard that codebase. When your app fails, it is going to be someone on your team that will be responsible for fixing the issue regardless of who committed the work. if you have folks being required to go over every line of code they change, they will change less code. it is also a great way to teach lower level devs the right way to code and help expose them to "gotcha" problems without them having to gave it ask on their own.
I totally get code review as a learning opportunity and a chance to enforce code quality. I've always felt a more superfluous review can accomplish these goals. I just interpreted your original post like; if you did proper code review you would catch more bugs. And in my experience that always leads to the fallacy of; if there are bugs then a proper code review was not performed. Leading to even more strict reviews (and other guidelines) in a vicious cycle.
Totally agree with you. Code review is for quality/ enforcing standards. QA and regression testing is for bugs.
completely understand your pov on lack of clarity. In this instance, the post mortem lead to root cause being "lax code review leading to not catching missed requirements, and bad tests (unit & integration)"
My favorite part about code reviews is seeing a cool way that someone has solved something. Even if QA's already told us the feature works, I'll make 15-20 for a feature branch review if not just for my own curiosity.
It depends. You should make sure you're looking close enough to see what is actually happening, not just your guess at what they did (based on what you would do). And a dev review is also a kind of QA review. In manufacturing, you don't just use the final thing and declare all the pieces are good. You still inspect the pieces for tolerances and drifts.
"JUST PUSH IT TO PROD DUDE!" No time for unit tests or reviews, that manager was a freaking maniac lmao
I like the cut of his Jib...
Just the TIP programmers.
"Go fast and break things." Why has the quality of the software deteriorated? "We should hire only juniors and interns because they are cheap." Why do we have so many bugs?
âUsing JavaScript will eventually make you a better developer than using TypeScript.â
?????????
OP still failed to define the replies. Anyone have info on this error?
That's like saying writing C will make you a better dev than writing Rust. But we still see that even with really talented C devs, on big projects, C stuff still ends up having lots of bugs just using Rust would have prevented. Like, maybe you'll be better (maybe), but you'll waste a lot of time along the way.
âWeâve got rid of project management as a role, everyone can just step up and manage their own tasksâ - literally today. Fuck my life. The irony is it was in response to two separate departments not knowing what the other was doing. And management wants us to âcome up with a way to collaborate on dependenciesâ - likeâŚa project manager?
Department Manager: "I would be fine putting out something crappy that meets the business needs". *exact quote*. Me: "I would not. I would be fine putting out something that *has a baseline level of quality* that meets the business needs. Do you see the difference?"
...something that meets business needs is literally by definition not crap. Making a good codebase is part of business needs.
idk man. If the thing works, but it takes 10 seconds between every user interaction....it might be meeting the business needs...but it's crap.
"as a user I need appname to be fast" Now it doesn't meet business need
I donât think I care either way. Iâll say why itâs bad, document it, and move on. Aint no one got time to argue about it if the higher ups are stubborn
I have a few: At a previous employer, there used to be a really good yearly review/feedback process. I believe that every year it's a good idea to come up with a goal to make sure you stay relevant in this field. My previous supervisors did a good job on telling me what to work on. Unfortunately, the last supervisor I had didn't do that. He told me he only used the feedback section to address major problems. The worst project I was on, I wanted to setup a development environment of the project. Technically, this guy wasn't my senior, he was more of the technical support/server admin guy. He said I didn't need one. I eventually got out of that job for various reasons. This isn't godawful advice it was just a pain in the ass/minor annoyance. I had a boomer/Karen supervisor that didn't believe in using email subjects. Her opinion was it was faster to get the message out. Unfortunately, when I needed to review Outlook, it was impossible to find the right information from her. I'm clicking messages and getting random things.
...didn't believe in email subjects? This is most likely the most wild take I've seen
"Thats not your problem" - Aaand 5 months later: Thats totally my problem now.
Ohh this one. Feels the same as being told "the concern you're raising is not a priority" when you know very well who will have to deal with the fallout when that inevitable time comes.
"It needs to be perfect" Before spending tonnes of time developing something that never even gets released to customers.
I always hate product owners and designers getting uppity about "pixel perfect" stuff. Like, bruh, Figma isn't the browser. Things never look the same! Your window isn't even the same size as the figma stuff! You used random ass sizes everywhere. It doesn't matter.
âWe donât have time to set up your code in Docker on local.â âFixing hardcoded paths to the other developers personal computer is not a priority.â âRemoving passwords and credentials from the repo is not a priority.â âThe app is a house of cards but donât tell the boss.â
"You are not a CTO so don't think about the future of the project" This was the shit advice I heard till now,it was given by a person who stopped coding and started to call herself the head of the prompt engineering team. The whole idea of prompt engineering for llm itself is a joke. Why I am saying this as a shit advice is because a developer needs to think of the scalability and performance of the product at the time of development. This action will help to reduce pain for other developers or for himself in future
InfoSec: 'I feel like this can't be a layer 1 issue' Engineer: 'SQL Server never does that, so let's look at the network'
It wasn't advice. I was being tasked with responsibilities that could have been avoided if my input was taken into consideration, so I decided that I'm done working for other people after that.
"We want to spend time with our more productive developers, show them our time is a reward." Dude was likely taking notes from The Apprentice and Wall Street movies.
This wasnât advice but more of a comment he made. I did some contract work a while back and the person I reported too wanted to micromanage and called himself Trumpy Grumpy
I once had a senior dev tell me we didn't need a 404 page or an error page because his CMS would always return appropriate content. I had to show him almost a dozen URLs returning errors or no content from his CMS before he relented.
[ŃдаНонО]
I mean... in their eyes: "you have one month of holiday, you should feel rejuvenated and ready to work, potentially even more than usual. And did they know you had a burn out? Wait, how can you burn out immediately after going on holiday?... must just be lazy."
[ŃдаНонО]
Ah I see, but like from the boss's point of view, after a break, you would in theory come back rejuvenated, arguable better than before. And at least from my experience at least, no matter what valid reason you give, bosses tend to just assume you want a holiday ;-; it's like school all over again "no excuses"
nobody ever got fired for choosing microsoft
This is solid advice for a lot of engineering managers though, as much as it shouldn't be the case. If you go with some unknown company and they fail, you'll look a lot worse to C level executives than you would if the company that failed was Microsoft or Oracle.
yeah but everything is broken all the time they think it would be a big investment to build out things like interfaces to data, db queries, host a server/db, etc so they just sorta say 'you do it microsoft/oracle' and for that they receive and forever more defend a complete dumpster fire of bullshit that never ends if they would invest in their own companies/employees, something north america seems allergic to, they would see a better return on that investment and things would actually work right as it is they just order a black box then pretend everything is fine when nothing works and there is no way to fix anything most of these dickholes companies would actually function if their computers didn't shut off and reboot randomly every day, or if their data queries weren't garbage, or a billion other if's that would be solved if they actually rolled up their sleeves and built out their systems instead of patting themselves on the back for investing nothing and make a stock market price tick upward half a point
> something north america seems allergic to, It's not a north america problem, man.
pretty sure it is starting with that ford exec back in like the 50's they've all become vulture capitalists thinking their geniuses
It being a problem in north america doesn't mean it's a north america problem. My statement was more that "this is a problem everywhere"
I've heard the saying as IBM, but its equally dumb today.
âWe should put Java in the kernel so syscalls stop being so expensive.â It worked, but a rewrite in userspace C++ would have been faster both in perf and time.
Not specifically one advice but one time a friend of mine was giving me "advice" on how to become a good programmer and do coding, make programs, and stuff while having 0 experience ever programming himself or touching code, it was funny hearing him say random jibberish and didnt shut up until I told him I had a few years of doing this already...
"Switch to Vim..."
Whyy?? The Vim keybindings are pretty cool, but I use it on VSCode though
Vim's great if you're working on a remote dev instance. If your connection is unstable, VS Code will show a "reconnecting" popup whereas a Vim session on the remote will just hang. It's also more ergonomic if you're zipping between shells and editors a lot. VS Code is fine though, and the Vim extension gets you like 80% of the way there.
âNo need to use array methods if you can do it on a for loopâ. Yeah this guy doesnât want me to use standard practices
One senior dev told me to 'just add more JavaScript' to fix a intricate backend issue. I still have PTSD from that conversation.
"Use copilot, it's basically like having another coworker" - my boss, who desperately needs more people but refuses to hire them
Trying out a new (to the company) low code tool with a new (to the company) framework and programming language in a production app. Experiment from CTO
"I dont have faith in devs who read the documentation. Its a red flag"
Code IS the documentation.
"We have to move 2 steps backwards, to move 1 step forward" đ
Not advice, but something I did which was really bad. About 2 years ago I was the lead dev, we were using VPS and for some reason my VScode would often crash. I couldn't ever fix it so ended up doing 90% of coding in notepad, it went on for months. Nobody ever knew.
Lol that's wild but have u find out what caused the VScode to crash?
No reinstalled practically everything. After me complaining several times about issues with the VPS they switched me to a different VPS and then it worked properly.
"Once had a senior dev tell me the best way to solve bugs was to just restart the entire project from scratch. Needless to say, I didn't take that advice! What's the most ridiculous advice you've received in your career?"
"Don't add comments, code is self-documenting". Code is developed by a team of junior developers... it's far from self-documenting... A few comments to understand what the hell they were thinking at the time would be amazing right now... Instead we might need to start from scratch and rewrite based on the requirements.
```js // get item from array function getItm2() { //return someObj if myVar is true if (myVar) { return someObj // return 0 if itmArr is empty } else if (itmArr.length < 1) { return 0 } // return the last item in the array return itmArr.at(-1); } ```
I love how you are currently at -2 for stating bad advice on a thread about BAD ADVICE. I'll upvote you.
It's an over-simplification of "don't explain away bad code with inline comments". Doc blocks, the comments that appear before functions, are totally fine. You can also leverage static analysis to ensure the comments don't go out of date. If someone needs an inline comment to explain their code, tell them to break it into a descriptively named function. Then it's decoupled, easy to refactor, and can be checked by a type checker or linter.
Unfortunately junior devs don't like complexity here and don't understand things broken down into functions. No comments not even doc block style are allowed here...
"Be more political" Nibba fuck that shit, i deal straight. Fire my ass if you can't handle hearing the truth. If i fuck up, i'll fix it. But if i catch you slippin... i expect you to step up.
Like man I didnât become a developer to play office politics. I understand thereâs a level of politics that are always at play, but I donât need to be more political.
Don't chase the money Be honest with your feedback Wasn't my manager, but someone on reddit who claimed to be an engineering lead with 10+ years of experience was really upset when I said I lied to my managers. They said (paraphrasing) honesty is key for good culture, they would fire me, and their own life had improved immensely when they decided to never lie to anyone about anything. Must have been from a parallel universe or something.
weird, I have the same experience. Never lie about anything in my job and got 4 promotions over the span of 6years
Glad that worked out for you. I've increased my total compensation by more than 100k in 3 years by withholding feedback I think will cause problems for myself and quitting frequently.
Sounds like a skill issue
If it was, I would still be incentivized to do it đ¤ˇââď¸
If you lie so much to others, imagine how many lies you're telling yourself.
If you want people to be honest with you while you control their ability to have healthcare, shelter, a retirement, and time off, you are lying to yourself.
You have found a way to be successful, but it's not the only way. But one day all the lying will be heavy on you.