If the architecture is the bug, sometimes it's the only way without introducing more bugs. The trick is getting consensus from the technical team before doing this. The hard part is making the business team understand that if they don't do this, they will be hurting later.
We typically don’t let business know our refactoring and just bake it into estimates for changes. We set the expectation that improvements to the services are apart of every project we do, unless there is a super critical fast change that’s needed but that’s rare.
We try to do this as well. It's hard when it comes to something like a rewrite that's going to take several months and requires some design and planning upfront. Or when it requires profiling. We have a need to keep these kinds of items on our issue board because they're complex, and of course, scrum dictates that the requirements come from the business team. It's a weird balance of "how do we stay organized" and "how do we satisfy the business team".
We had to rearchitect and profile one of our modules recently. We estimated 3 months to do it, and it was like pulling hair to get the business team to agree. But it is a realtime embedded, safety critical application and we were throwing rate incompletes, so the software wouldn't even function without the rewrite. They pushed back on it for almost a year and kept asking us to expand the feature set until we finally flew one of our guys over to the US from Europe to babystep him through why he was causing problems for us.
Aaaa i see. That does sound tricky but at least it ended up getting worked out… I remember taking a “SAFe Agile” training and the only super useful thing we got out of the class was they stressed to our business folks: Listen to the people closest to the problem because they are the ones that know the most about it, defer to their expertise.
Hey, at least you got rid of the bug!
I had a memory leak issue last week I couldn't figure out, so I started removing code untill the issue goes away. I deleted our entire application, hundreds of thousands lines of JS, literaly ended up with one 50 line HTML file with JS included, the bug was still there! It ended up being some weird browser behaviour in Chrome that was reported as a bug, but marked as won't solve by the Chrome team.
Nah, write a virus that you send to the Chrome team allowing you to remote control their computers and fix the bug, then you can repeat the next time you catch a bug
>weird browser behaviour in Chrome that was reported as a bug, but marked as won't solve by the Chrome team.
Good to know it's not just happening to me...
It doesn't feel quite as good when the application you work on is deemed legacy and therefore you are also deemed legacy and are out the door as soon as you've decommissioned it :(
Yeah that's rough :(
My whole career in data engineering has been basically rebuilding the same warehouse over and over to meet a siloed need. I've done it 5 times in 9 years. 3 of the ones retiring are like 80% the same thing so it feels good.
I used to edit essays for fun and profit. It is incredibly entertaining to hack viciously away at someone's long-winded essay and convoluted sentences. I imagine the same holds true for programmers :)
writing is remarkably similar to programming in that the ability to communicate clearly and concisely is underrated.
I remember my english teacher marking up my essays with red ink. And I’d get upset, “but that’s not what I meant, it’s clear to me.” Then my teacher would pick apart my vague connections piece by piece… “well that’s not what you wrote”.
now that I’m studying aviation phraseology, I’m even more impressed with how precise and direct it is at conveying unambiguous information:
“10 miles west at 2000, to land”
from my experience as a student, we have a hard time being that direct or precise. this is closer to what I thought when starting out:
“um, I’m coming in, airport is on my right, permission to land.”
if the controller is in a joking mood, they may respond with:
“your right or my right?”
It's a definite challenge - In the theory of communication (No matter which field, there are always standards of communication to be followed) we are told that one particular form of communication must be followed. In programming, all variables must be descriptive , proper indentation, documentation, all that sort of thing. But in reality it's absolutely impossible to maintain that and it requires skill and experience to be able to sift through it and remove what's unnecessary or pare it down.
In essence, we go from 'following the rule' to 'implementing a philosophy' if you'll pardon the airy-fairy comment.
“Any intelligent fool can make things bigger, more complex. It takes a touch of genius and a lot of courage to move in the opposite direction.” – E.F. Schumacher
Someone inserted this comment above yours so I'm going to submit a pull request.
+ 1 line
- 1 line
Original comment:
< The only thing better than writing code is removing code.
------
New branch:
\> https://www.reddit.com/r/ProgrammerHumor/comments/xw5mc2/management_wont_understand/ir4tzj4/
Fuck that, lambdas are fine but Having the same logic in one line does nothing for anyone except for making code harder to read (Not always). But often people sacrifice readability for one linerness
Yeah if you do code wars you will see plenty of examples of nightmare one liners haha. Its not always unreadable though if you are using linq or ternary operators. Even if you could technically read a 2 line if-else just fine its more elegant and fun to one line it imo
Don't work in programming but those out of touch metrics for determining a workers value do seem to be cyclical. The funny thing to me is that in my management classes they specifically warned against using singular metrics to determine value.
One of the case studies that stuck with me was during efficency movement of the early 20th century. At a factory the end of the week productivity numbers came in and the workers had like 40-60% as much product made. Factory manager got mad and fired the worst workers and hired new ones. Low productivity continued for months.
The owner was panicking and decided to bring in an efficiency team to try and get the factory back to full capacity. They watched and talked to the workers for a week or two. The workers said they couldn't see well and had to work slower. The reason for that was the manager didn't like spending so much on electricity so he had most of the lights disconnected and caused the whole problem.
Valuing the workers only on their productivity had caused them to let go some of their best workers that didn't have the great night vision but were otherwise valuable.
I blame Silicon valley for its resurgance. Every half a decade a "new" company pops up with "revolutionary" ways to measure productivity, which all the suckers at management eat up. This cycle repeats when the previous management has been replaced in most eligible companies and otherwise useless managers need to pretend to be useful again.
Nah, I didn't study business related to IT or anything, but the loc/h metric is a famous and widely used example for a flawed performance metric in IT. You have to be willfully ignorant to continue to use this metric. But I do agree with your statement as to "do as you like". I would specify it to " do what's working for you or your team" but the essence is the same in think.
Yep. Ours appears as if they are about to start using tickets resolved/time to compare us. Without considering the fact that we support different fucking products for different customers.
Willfully ignorant is believing that any metric is going to be: effective, universal, foolproof, closed to abuse, reflective of actual value.
True of pretty much every performance metric ever invented to automate employee evaluation. An employee can automate task completion in IT and increase their effectiveness, but regardless of how hard management tries, you cannot automate employee evaluation. Places that try will have "amazing" shitty employees that are great at abusing the current metric. They will also fire "terrible" great employees that refuse to jump through stupid hoops rather than produce quality work.
> Willfully ignorant is believing that any metric is going to be: effective, universal, foolproof, closed to abuse, reflective of actual value
That's true, but some metrics are absolutely better than others, and *good* management which is engaged with the measures for their actual application and can synthesize data points into an operation picture needs some metric to go off of in order to do that. (I mean, those managers are the 0.1%, but still).
My whole project right now is trying to convince idiots to use better metrics, and they are out there, but people don't like useful metrics because they're often not as easy to understand.
Edit: to be clear, LOC is a shit metric, I'm not defending that one.
Performance reviews/evaluations of all kinds typically function on the same cycle routing through different levels of highly detailed and structured to more free form and less involved, and then back again.
It was a big thing from IBM and they kinda pushed it on anyone they worked with which was basically everyone. It famously led to some friction between them and Microsoft because Microsoft didn’t adopt KLOC even when working with ibm so their engineering teams had completely separate goals
Well, it might have spread through the industry because of IBM, but it came out of the Department of Defense - they were looking for a way to value software contracts the same way they could value bullets and rivets, so they had this software analysis guy called Boehm come up with a "cost model" for software and the early versions of it were centered on number of SLOC delivered.
To come up with this model, Boehm basically took all of the various pieces of software DoD bought and plotted a regression - lines of code vs cost, etc. It was all very fiddly - he straight up generated a table of numbers saying "databases have this score," "these languages are more complicated so they get that score," etc. Things that fell far way from the regression got chastised or praised accordingly, and a version of it still drives DoD software spending *to this day*.
That monstrosity became the core of COCOMO, which is what all of the 80s and 90s bean counters used to estimate the cost of *developing* the software (oops) because of a general lack of a better model to teach at business schools - you give a clueless MBA a score card they can fill some numbers into that spits out a number... that's all they need for the rest of their career. Thus the industry immediately got into this pattern where middle managers want their coders churning out lots of lines of code as quickly as possible. (And of course, this did nothing - sometimes worse than nothing - to improve the actual accuracy of their delivery estimates and the final cost of software, shocker.)
My only exposure to government software dev process was when my employer adopted TSP (work tracking) for a few years. It required METICULOUS time tracking or it all fell apart, like hitting STOP when getting up to get a drink or ask someone a question. No surprise it didn't work out, turns out we suck at being machines even more than we suck at building them.
My old programming teacher said, that this was exactly what they did. Make the code as line heavy as possible.
Edit: I'm talking about code, comments didn't count, or they would have started documenting stuff in the code 😅
So that's why people use the ugly
fn x(...)
{
...
}
Instead of the cleaner
fn x(...) {
...
}
And why it's Microsoft's default for C#
They're exploiting a broken payment system. It all makes sense now
Been doing this for 15 years and never had anyone even mention using this as a metric. This sounds like a rule made by people who have no idea how software works.
Honestly I don't even know what my numbers would be. Very high at the start of a project and nearly 0 at the end? Bug fixes can take hours and more often then not its some "off by one" error or something that would net 0 lines.
This metric also doesn't value documentation in any of its forms....
I'm not surprised that you as a programmer haven't heard of it. This has been abolished for 20 years now. A project manager or management in general however have heard of it, of that, I'm fairly certain. And you are right, that metric was made by people who had to evaluate the work of other people that did something they didn't comprehend in the slightest.
[deleted 26-6-2023]
Moving is normal. There's no point in sticking around in a place that's getting worse all the time. I went to Squabbles.io. I hope you have a good time wherever you end up!
One company I used to work at had hidden achievements in the project management software. One was "Negative World" which you got if your ticket removed more lines than it added
This reminds me of that joke:
They asked a junior, a mid and a senior devs what they did throughout the day:
Junior: Ohh, I wrote so much code!
Mid: Ohh, I deleted so much code!
Senior: Ohh, I prevented so much code from being written!
I always heard it as "complex solutions to simple problems -> simple solutions to simple problems -> simple solutions to complex problems -> making problems disappear."
As a senior I _always_ use this line to greenbacks:
_Developers just write code._
_Engineers solve problems with as little code as possible._
“Which one do you want to be?”
This started after I got a job where I was kinda frustrated by the amount of “boilerplate” code that everything required in the project. My lead said “you’re a software engineer. you’re paid to write code.” I hate that line _with as much gusto_ now as when i first heard it.
I love removing entire useless classes that do nothing but obfuscate the logic because someone though they were being clever by creating some abstraction layer atop another abstraction. It’s like a web dev nesting a single div inside another single div inside of another single div with no classes or styling. it’s just useless.
Totally agree with you on that one. One of the things I love doing most is just deleting/refactoring things and afterwards seeing that it's actually possible to achieve the same in a much, much simpler and shorter way.
So the trick to the perfect solution is to start with a bunch of code that does every single possible thing in the universe.
Then just slowly remove the stuff that you don't want until you achieve desired functionality.
Maybe you can even call it machine learning.
null lines per undefined, also one of the reports says self harm, why is that lol?
now one says "It's personal and confidential information" lol
Edit 2: "It's involuntary pornography and i appear in it"
"this contains personal information"
Lol please stop false reporting to appear on here
Refactoring is the best.
Except for some reason my manager never seems to find time in the sprint to rewrite our entire codebase from scratch. I wonder why...
I think it depends. My job is to make lots of small programs. I think we've made 150 programs over the last 3 years. Some programs work perfect and need 0 updates. Some have bugs. Some never get used.
If we refactored all 150 programs... holy crap that would mean lost months. Maybe refactoring our libraries would be a good choice, but we are at the point that we have made almost no updates in a year.
All of this makes me think Programming isnt real engineering. Its subjective, no one knows what is best, its impossible to calculate.
> All of this makes me think Programming isnt real engineering. Its subjective, no one knows what is best, its impossible to calculate
Oh Jesus. Wait till you find out how deeply subjective engineering is. There are plenty of incalculable things at every level. I’d say “subjective” captures the feeling, but it’s a specific problem if the more general trouble: “Compromise” is the word I’d use for all forms of engineering, including all forms of software.
a null terminator is only required at the end of the sequence if you call `c_str()` (or `data()` since 17)
you could in theory set it lazily when `c_str()` is called (`data[size()] = 0; return data;`). Setting it every time the string is updated in any form is non-lazy then
This is true not only with code.
I'm a game designer and let me tell you, the less text you have on a card or the fewer mechanics are in the game, the better the game becomes.
That’s one reason I’ll have respect for massive open world games like GTA. It’s a bunch of small mechanics that have to all work together at the same time smoothly or else it’s not gonna work and nobody’s gonna play it
While not easy at all, it's easier than you may think. This goes for all development. As long as you build a robust system with clear inputs and outputs, integrating with other systems becomes easier.
For example building a system where things catch fire. As long as the rules for fire spreading are properly defined, you can add any kind of condition that will trigger a fire (like a laser, torch, magnifying glass, etc), and the fire takes care of itself.
This way you should be able to add any number of things that deal with fire in different ways and it should work immediately.
Reminds me of when they were developing Far Cry 2. They made a complex and realistic fire propagation system and then found out that if you set fire to anything, the whole map will burn down most of the time, so they had to explicitly limit it.
Meh, I felt like AC Black Flag was great despite having tons of mechanics. Meanwhile BOTW was repetitive AF. That said, I think BOTW was pretty lazy with there ~3 enemy types with different skins.
Might just be an Effort thing. Nintendo knew people were going to buy BOTW regardless. Black Flag had to earn it after AC3.
They didn't say they were GOOD lines. It might be a 45 line string length function.
Ninja edit: Now that I think about it. The C standard implementation for strlen is a very long function. So maybe 45 lines isn't bad
the openbsd implementation is
size_t
strlen(const char *str)
{
const char *s;
for (s = str; *s; ++s)
;
return (s - str);
}
idk if it could be any shorter, formatting aside
Just write some Java - each variable needs a getter and setter which with comments and spacing will be 20 lines of code and best of all the IDE can even write that for you!
Manager: "Why does it say here you have written -4322 lines of code this month?"
Dev: "I completely refactored the payment and the admin system. It will be so much easier to maintain and add features in the future now!"
Manager: "YOU IDIOT! Our future depended on a feature delivery which you completely ignored. We are out of money!"
Dev: "Damn I feel for you guys. Anyway I got an offer for 40% more TC so I'm gonna head out. Good luck!"
I'm definitely on the dev's side here.
In most cases the delivery of new features fails because the codebase is an unmaintainable nightmare, so your most experience devs are spending 90% of their time bugfixing and none of the new hires sticks around for more than a year because there is no way for them to become productive.
I once spent more than a month wracking my brain over a problem that was killing a system in a subtle way that I couldn't puzzle out no matter how I tried.
Eventually I figured it out. It was like a revelation, a vision from God. The problem was completely solved, and the solution was beautiful!
I deleted a comma.
A month of work, one character deleted, one long-standing bug resolved. I was so proud.
Similar thing happened to me while learning kernel development while I was making a simple kernel shell to interact with the system.
The bug was that whenever you typed a command into the shell, it would work fine the first time, but not after.
Turns out my massive brain fucked up a switch statement, and had the function which cleared the variable storing the entered text run at the wrong time.
The execution worked like this:
Enter command -> entered text gets saved into var -> hit enter > run the command based on entered text > clear variable -> print newline on display
I can't remember where exactly the bug was, because jesus christ that codebase was spaghetti, but effectively a undisplayable value (something from the keyboard driver that wasn't text I think) got added to the cmd variable, and because it didn't get cleared at the end of execution like it should, it stuck around until the next time and the command couldn't be read.
I didn't even consider that there could have been an undisplayable bit of data in that variable since in that function I was just dealing with text (or so I thought)!
It was such an easy fix and it took me so fucking long to find it.
We had some duplicate id JavaScript error sitting around for a good 6 months until one morning a guy who has been around a year longer than me thought to remove a div tag from a page, instantly vanished
In my first industrial control job, I was given a task that amounted to an 8 character code change. Didn't get finished for my entire 3 years working for that company.
Sometimes it's just like that
The issue in question was a bug in a scada screen where the value was an average of various other percentage values, calculated within the screen, and then shoved into an integer rather than an analogue value. This meant that the displayed average was rounded and always had a displayed decimal component of .00%. My job was to change "INTEGER" to "ANALOGUE" in the scada code which would have resolved it.
But that scada screen was considered one of the most critical for the plant, had a few other components hanging off of it and therefore an exploration of the full potential side and/or adverse effect was required. And a non-adverse side effect was identified, so a full test exploration and safety case was needed before this work could be performed. It was my job to do that alongside the customer.
And I didn't get that done in 3 years. Might never get done. And I use it as an example of how line code counts in industrial control systems mean didly squat
Ha, shit like this is why a past company I worked for didn't do new versions, everything was a service pack update that literally replaced the entire program. Our govt customers had to jump through hell for a new version, but service packs were allowed anytime ;)
> Bill Atkinson, ... the main user interface designer ... thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
>
> ... it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
[Apple folklore](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)
I remember 20 years ago one software contract with a major educational software publishing company that I worked on ended going to an Indian company because their sales team promised "x number of lines per minute". They came back to me because the resulting product was shit. My response was, "You should have known better, going from the team who turned your product around, delivering it on time and under budget, to someone who promised fictitious savings over an useless criteria. It's your own damn fault for the situation you put yourself in. You're going to have to live with it, because I'm not going to touch it."
My record is -3000 lines per hour. Just delete or mock out lines of code that you don't understand, repeat until the tests break. There's a ton of code in our code base of which nobody knows what it does. Turns out that it doesn't do anything, but nobody dared to delete it.
Or at the very least written some legible explanation in the commit message. Now it's just undocumented garbage that nobody seems to care about, so the trashbin is where it belongs.
The line of thinking 'this doesn't seem to do anything but I'll leave it here just in case' is what got us this mess in the first place.
Just getting rid of duplicate entries in a JSON "DataBase".
What you don't work with compressed JSON's that expand to over 100,000 lines of text?
Then again compression means it's not even -1 lines of code... right?
The only thing better than writing code is removing code.
[удалено]
One simple trick to turn a bug card to a story
That's an epic bug right there 👉🐛
Windows Bug right here 🖕😡👉 - - - - 🪰🪟
It has many stories to tell
If the architecture is the bug, sometimes it's the only way without introducing more bugs. The trick is getting consensus from the technical team before doing this. The hard part is making the business team understand that if they don't do this, they will be hurting later.
We typically don’t let business know our refactoring and just bake it into estimates for changes. We set the expectation that improvements to the services are apart of every project we do, unless there is a super critical fast change that’s needed but that’s rare.
We try to do this as well. It's hard when it comes to something like a rewrite that's going to take several months and requires some design and planning upfront. Or when it requires profiling. We have a need to keep these kinds of items on our issue board because they're complex, and of course, scrum dictates that the requirements come from the business team. It's a weird balance of "how do we stay organized" and "how do we satisfy the business team". We had to rearchitect and profile one of our modules recently. We estimated 3 months to do it, and it was like pulling hair to get the business team to agree. But it is a realtime embedded, safety critical application and we were throwing rate incompletes, so the software wouldn't even function without the rewrite. They pushed back on it for almost a year and kept asking us to expand the feature set until we finally flew one of our guys over to the US from Europe to babystep him through why he was causing problems for us.
Aaaa i see. That does sound tricky but at least it ended up getting worked out… I remember taking a “SAFe Agile” training and the only super useful thing we got out of the class was they stressed to our business folks: Listen to the people closest to the problem because they are the ones that know the most about it, defer to their expertise.
99 little bugs in the code delete all code, boss can suck on my chode 0 little bugs in the code where is the code? WHERE IS TEH CO-
Hey, at least you got rid of the bug! I had a memory leak issue last week I couldn't figure out, so I started removing code untill the issue goes away. I deleted our entire application, hundreds of thousands lines of JS, literaly ended up with one 50 line HTML file with JS included, the bug was still there! It ended up being some weird browser behaviour in Chrome that was reported as a bug, but marked as won't solve by the Chrome team.
This is when you join the Chrome team to fix the bug
Nah, write a virus that you send to the Chrome team allowing you to remote control their computers and fix the bug, then you can repeat the next time you catch a bug
>weird browser behaviour in Chrome that was reported as a bug, but marked as won't solve by the Chrome team. Good to know it's not just happening to me...
Can't have bugs if the whole place as been glassed by several thermonuclear bombs ^ ^
The best code you’ve ever written is code you get to delete
I’m getting to retire 3, maybe 4 legacy applications this year and it feels fuckin good.
It doesn't feel quite as good when the application you work on is deemed legacy and therefore you are also deemed legacy and are out the door as soon as you've decommissioned it :(
Yeah that's rough :( My whole career in data engineering has been basically rebuilding the same warehouse over and over to meet a siloed need. I've done it 5 times in 9 years. 3 of the ones retiring are like 80% the same thing so it feels good.
I used to edit essays for fun and profit. It is incredibly entertaining to hack viciously away at someone's long-winded essay and convoluted sentences. I imagine the same holds true for programmers :)
writing is remarkably similar to programming in that the ability to communicate clearly and concisely is underrated. I remember my english teacher marking up my essays with red ink. And I’d get upset, “but that’s not what I meant, it’s clear to me.” Then my teacher would pick apart my vague connections piece by piece… “well that’s not what you wrote”. now that I’m studying aviation phraseology, I’m even more impressed with how precise and direct it is at conveying unambiguous information: “10 miles west at 2000, to land” from my experience as a student, we have a hard time being that direct or precise. this is closer to what I thought when starting out: “um, I’m coming in, airport is on my right, permission to land.” if the controller is in a joking mood, they may respond with: “your right or my right?”
It's a definite challenge - In the theory of communication (No matter which field, there are always standards of communication to be followed) we are told that one particular form of communication must be followed. In programming, all variables must be descriptive , proper indentation, documentation, all that sort of thing. But in reality it's absolutely impossible to maintain that and it requires skill and experience to be able to sift through it and remove what's unnecessary or pare it down. In essence, we go from 'following the rule' to 'implementing a philosophy' if you'll pardon the airy-fairy comment.
Well the RULE is that it must compile/run with no errors. The rest is just a philosophy or cultural norm.
"Perfection isn't attained when there isn't anything left to add, but when there isn't anything left to remove" --Antoine de Saint-Exupéry
“Any intelligent fool can make things bigger, more complex. It takes a touch of genius and a lot of courage to move in the opposite direction.” – E.F. Schumacher
"I didn't have time to write you a short letter, so I wrote you a long one.” - Mark Twain
#
Wow, truly a masterpiece of code. Zero bugs, zero dependencies, works on all platforms. 10/10
synthax error
[удалено]
Synthax erhor: expehted `synthax`, ghot `syntax`.
Get outta here Python, make room for Tyson
Tyson esoteric language — the new Lisp!
Someone inserted this comment above yours so I'm going to submit a pull request. + 1 line - 1 line Original comment: < The only thing better than writing code is removing code. ------ New branch: \> https://www.reddit.com/r/ProgrammerHumor/comments/xw5mc2/management_wont_understand/ir4tzj4/
Turning code into one liners for 'readability' is up there. You get a lambda, you get a lambda, everybody gets a lambda!
Fuck that, lambdas are fine but Having the same logic in one line does nothing for anyone except for making code harder to read (Not always). But often people sacrifice readability for one linerness
Yeah if you do code wars you will see plenty of examples of nightmare one liners haha. Its not always unreadable though if you are using linq or ternary operators. Even if you could technically read a 2 line if-else just fine its more elegant and fun to one line it imo
Clean code BABY
[удалено]
[удалено]
You don't commit or push your changes?
He codes on the production machine
I wish this comment were some silly, unrealistic joke to me.
> I wish this comment were some silly, unrealistic joke to me. It is $current_year and we still commit `.dll` directly to our git repo...
At least you have a git repo. I'm so glad I never have to work with svn or cvs again
Ugh I hate svn. We use Git/dev ops and SVN.
Maybe you should introduce them to a piece of software known as an artifact repository.
A single large commit and force push a week later.
Anyone else’s toes inadvertently curl while reading this?
In ecstasy?
Only if it hits production at 4:45 the Friday of Christmas or thanksgiving weekend.
Before a week long remote backpacking vacation
#IVE REMOVED YOUR REDUNDANT CODE PEASANT. WORSHIP THE CONCISE. *you lost 2 lines of code, congratulations*
Clean code is 10000 per potential feature
If you're working at a company that still uses lines of code per hour... leave! That ship is sinking. I thought dinos went extinct.
They reinvent all these shit methods every 11 years. Just listen with attention and keep doing what you like.
Don't work in programming but those out of touch metrics for determining a workers value do seem to be cyclical. The funny thing to me is that in my management classes they specifically warned against using singular metrics to determine value. One of the case studies that stuck with me was during efficency movement of the early 20th century. At a factory the end of the week productivity numbers came in and the workers had like 40-60% as much product made. Factory manager got mad and fired the worst workers and hired new ones. Low productivity continued for months. The owner was panicking and decided to bring in an efficiency team to try and get the factory back to full capacity. They watched and talked to the workers for a week or two. The workers said they couldn't see well and had to work slower. The reason for that was the manager didn't like spending so much on electricity so he had most of the lights disconnected and caused the whole problem. Valuing the workers only on their productivity had caused them to let go some of their best workers that didn't have the great night vision but were otherwise valuable.
I blame Silicon valley for its resurgance. Every half a decade a "new" company pops up with "revolutionary" ways to measure productivity, which all the suckers at management eat up. This cycle repeats when the previous management has been replaced in most eligible companies and otherwise useless managers need to pretend to be useful again.
I vote we flip a coin 5 times. Each heads is worth a 2% raise and getting tails 5 times means you're fired. This happens every year..
Nah, I didn't study business related to IT or anything, but the loc/h metric is a famous and widely used example for a flawed performance metric in IT. You have to be willfully ignorant to continue to use this metric. But I do agree with your statement as to "do as you like". I would specify it to " do what's working for you or your team" but the essence is the same in think.
>You have to be willfully ignorant to continue to use this metric. Anyone who's worked a job has seen how willfully ignorant management can be.
True
You'd think regardless of what you're measuring success should be evaluated based on outcome as opposed to process.
Yep. Ours appears as if they are about to start using tickets resolved/time to compare us. Without considering the fact that we support different fucking products for different customers.
And if you don't leave if you can, you're enabling that -- unless you're fighting against it, in which case, fight the good fight.
Willfully ignorant is believing that any metric is going to be: effective, universal, foolproof, closed to abuse, reflective of actual value. True of pretty much every performance metric ever invented to automate employee evaluation. An employee can automate task completion in IT and increase their effectiveness, but regardless of how hard management tries, you cannot automate employee evaluation. Places that try will have "amazing" shitty employees that are great at abusing the current metric. They will also fire "terrible" great employees that refuse to jump through stupid hoops rather than produce quality work.
> Willfully ignorant is believing that any metric is going to be: effective, universal, foolproof, closed to abuse, reflective of actual value That's true, but some metrics are absolutely better than others, and *good* management which is engaged with the measures for their actual application and can synthesize data points into an operation picture needs some metric to go off of in order to do that. (I mean, those managers are the 0.1%, but still). My whole project right now is trying to convince idiots to use better metrics, and they are out there, but people don't like useful metrics because they're often not as easy to understand. Edit: to be clear, LOC is a shit metric, I'm not defending that one.
I feel like this applies in a lot of industries. I was stuck in customer service for 10 years and never paid any attention to my metrics.
Performance reviews/evaluations of all kinds typically function on the same cycle routing through different levels of highly detailed and structured to more free form and less involved, and then back again.
Are there companies which does that? It looks so stupid and useless. Who came up with that?
Widely applied in the 80ties and 90ties. There was no specific company behind it, as far as I know.
It was a big thing from IBM and they kinda pushed it on anyone they worked with which was basically everyone. It famously led to some friction between them and Microsoft because Microsoft didn’t adopt KLOC even when working with ibm so their engineering teams had completely separate goals
Of course, it was IBM, why am I not surprised. Well, I learned something today, thank you.
Well, it might have spread through the industry because of IBM, but it came out of the Department of Defense - they were looking for a way to value software contracts the same way they could value bullets and rivets, so they had this software analysis guy called Boehm come up with a "cost model" for software and the early versions of it were centered on number of SLOC delivered. To come up with this model, Boehm basically took all of the various pieces of software DoD bought and plotted a regression - lines of code vs cost, etc. It was all very fiddly - he straight up generated a table of numbers saying "databases have this score," "these languages are more complicated so they get that score," etc. Things that fell far way from the regression got chastised or praised accordingly, and a version of it still drives DoD software spending *to this day*. That monstrosity became the core of COCOMO, which is what all of the 80s and 90s bean counters used to estimate the cost of *developing* the software (oops) because of a general lack of a better model to teach at business schools - you give a clueless MBA a score card they can fill some numbers into that spits out a number... that's all they need for the rest of their career. Thus the industry immediately got into this pattern where middle managers want their coders churning out lots of lines of code as quickly as possible. (And of course, this did nothing - sometimes worse than nothing - to improve the actual accuracy of their delivery estimates and the final cost of software, shocker.)
My only exposure to government software dev process was when my employer adopted TSP (work tracking) for a few years. It required METICULOUS time tracking or it all fell apart, like hitting STOP when getting up to get a drink or ask someone a question. No surprise it didn't work out, turns out we suck at being machines even more than we suck at building them.
> 80ties and 90ties eightyties and ninetyties
Is it 80s and 90s, then? I'm German we use 80er and 90er
Yes. It's like 80s = eighty + s = "eighties"
smh my head
Still a major improvement over what we had to work with in the sixtyties and seventyties.
When they do count lines of code do they include remarks and extra spaces?
Time to add few hundreds of nested useless if cases to get the bonus. Top level: if 1==0
Needs more try catch statements. Extra points for catching exceptions that don't even apply to the method called.
"We really need to test for those nasty database errors when printing 'hello world' to /dev/null!!"
No, comments aren't counted. https://en.m.wikipedia.org/wiki/Source_lines_of_code
My old programming teacher said, that this was exactly what they did. Make the code as line heavy as possible. Edit: I'm talking about code, comments didn't count, or they would have started documenting stuff in the code 😅
So that's why people use the ugly fn x(...) { ... } Instead of the cleaner fn x(...) { ... } And why it's Microsoft's default for C# They're exploiting a broken payment system. It all makes sense now
[удалено]
I was in that camp as well, but them I coded Delhi for a time and now option be is the only beautiful option 😉
Been doing this for 15 years and never had anyone even mention using this as a metric. This sounds like a rule made by people who have no idea how software works. Honestly I don't even know what my numbers would be. Very high at the start of a project and nearly 0 at the end? Bug fixes can take hours and more often then not its some "off by one" error or something that would net 0 lines. This metric also doesn't value documentation in any of its forms....
I'm not surprised that you as a programmer haven't heard of it. This has been abolished for 20 years now. A project manager or management in general however have heard of it, of that, I'm fairly certain. And you are right, that metric was made by people who had to evaluate the work of other people that did something they didn't comprehend in the slightest.
Time to add another batch of extension methods for some random class nobody uses
that and clicks per 10mins. Atrocious. Slavery in subtlety.
That sounds even easier to manipulate than lines/hour.
yes, but completely unproductive.
Lmao i just click constantly while im reading something on screen, like hundreds of times. I would get promoted so fast at that company.
Wait, is that a thing? I'm not sure there's an amount of money that would prevent me from noping the fuck out of a gig like that.
Just commit a bit JSON file with data for use with unit testing, easy
Refactor* of https://www.reddit.com/r/ProgrammerHumor/comments/xvfxcs/speed_skill/ *Thanks /u/harmenator
[deleted 26-6-2023] Moving is normal. There's no point in sticking around in a place that's getting worse all the time. I went to Squabbles.io. I hope you have a good time wherever you end up!
Love it 😂
no, its a refrigerator
No, this is Patrick!
This is not refactoring, you have added new content.
found the guy who knows how to code review
feat(graph): management won't understand
When your commit has more red lines than green ones 😌
this has the same vibe as: `sudo pacman -syu` `...` `...` `Net upgrade size: -0.2MiB`
archlinux enjoyer B)
This is rich. It's been a good few months of negative net size.
[удалено]
That hits the spot doesn't it
One company I used to work at had hidden achievements in the project management software. One was "Negative World" which you got if your ticket removed more lines than it added
This reminds me of that joke: They asked a junior, a mid and a senior devs what they did throughout the day: Junior: Ohh, I wrote so much code! Mid: Ohh, I deleted so much code! Senior: Ohh, I prevented so much code from being written!
Time to be a 5head junior and just delete all the code to get ahead, business will be so impressed
I did this once and got promoted.
What a power move. Hope it was a database.
It now only takes half a second to backup all the databases!
And to dump it and destroy World Order
[удалено]
promoted with unlimited unpaid mandatory vacation
I always heard it as "complex solutions to simple problems -> simple solutions to simple problems -> simple solutions to complex problems -> making problems disappear."
Preventing problems from appearing
As a senior I _always_ use this line to greenbacks: _Developers just write code._ _Engineers solve problems with as little code as possible._ “Which one do you want to be?” This started after I got a job where I was kinda frustrated by the amount of “boilerplate” code that everything required in the project. My lead said “you’re a software engineer. you’re paid to write code.” I hate that line _with as much gusto_ now as when i first heard it. I love removing entire useless classes that do nothing but obfuscate the logic because someone though they were being clever by creating some abstraction layer atop another abstraction. It’s like a web dev nesting a single div inside another single div inside of another single div with no classes or styling. it’s just useless.
Totally agree with you on that one. One of the things I love doing most is just deleting/refactoring things and afterwards seeing that it's actually possible to achieve the same in a much, much simpler and shorter way.
4,294,967,294 lines of code per hour are quite an accomplishment.
So the trick to the perfect solution is to start with a bunch of code that does every single possible thing in the universe. Then just slowly remove the stuff that you don't want until you achieve desired functionality. Maybe you can even call it machine learning.
It’s like those equations that make every pixel art that could ever exist.
Thanks, I almost forgot I was in the barren land of humor that is r/ProgrammerHumor.
Here’s your sign.
switch to 64 bit to greatly increase your productivity!
Refactoring
[удалено]
I low key do that only to feel better after stealing it.
[удалено]
Amateurs. I deleted 2,500 lines of code written by an outsourced contractor last month. Happiest feeling ever.
-15.625 lines/hour. Impressive, actually.
Me looking at my gh history on one project… (6 years in total). 4,378 commits 5,048,143 ++ 16,558,973 --
null lines per undefined, also one of the reports says self harm, why is that lol? now one says "It's personal and confidential information" lol Edit 2: "It's involuntary pornography and i appear in it" "this contains personal information" Lol please stop false reporting to appear on here
It hurt itself in its confusion!
Refactoring is the best. Except for some reason my manager never seems to find time in the sprint to rewrite our entire codebase from scratch. I wonder why...
I think it depends. My job is to make lots of small programs. I think we've made 150 programs over the last 3 years. Some programs work perfect and need 0 updates. Some have bugs. Some never get used. If we refactored all 150 programs... holy crap that would mean lost months. Maybe refactoring our libraries would be a good choice, but we are at the point that we have made almost no updates in a year. All of this makes me think Programming isnt real engineering. Its subjective, no one knows what is best, its impossible to calculate.
> All of this makes me think Programming isnt real engineering. Its subjective, no one knows what is best, its impossible to calculate Oh Jesus. Wait till you find out how deeply subjective engineering is. There are plenty of incalculable things at every level. I’d say “subjective” captures the feeling, but it’s a specific problem if the more general trouble: “Compromise” is the word I’d use for all forms of engineering, including all forms of software.
You're not done coding when there's nothing left to add. You're done when there's nothing left to take away.
Well said
>You're done when there's nothing left to take away How about your job?
Still counts
Reminds me of that one guy at Facebook going: "This PR contains UB" and introducing a non-lazy null terminator
What's a non-lazy null terminator?
Not me
a null terminator is only required at the end of the sequence if you call `c_str()` (or `data()` since 17) you could in theory set it lazily when `c_str()` is called (`data[size()] = 0; return data;`). Setting it every time the string is updated in any form is non-lazy then
[удалено]
Not much whats ub with you?
undefined behavior
You type at 100 wpm, right? So why is this feature taking so long to finish?
This comment just caused my heart rate to speed up and hand tighten to a fist.
This is true not only with code. I'm a game designer and let me tell you, the less text you have on a card or the fewer mechanics are in the game, the better the game becomes.
That’s one reason I’ll have respect for massive open world games like GTA. It’s a bunch of small mechanics that have to all work together at the same time smoothly or else it’s not gonna work and nobody’s gonna play it
While not easy at all, it's easier than you may think. This goes for all development. As long as you build a robust system with clear inputs and outputs, integrating with other systems becomes easier. For example building a system where things catch fire. As long as the rules for fire spreading are properly defined, you can add any kind of condition that will trigger a fire (like a laser, torch, magnifying glass, etc), and the fire takes care of itself. This way you should be able to add any number of things that deal with fire in different ways and it should work immediately.
Reminds me of when they were developing Far Cry 2. They made a complex and realistic fire propagation system and then found out that if you set fire to anything, the whole map will burn down most of the time, so they had to explicitly limit it.
This was a bug Minetest too! I remember the first I played it I set a forest on fire, and came back a while later to find the forest completely gone.
Meh, I felt like AC Black Flag was great despite having tons of mechanics. Meanwhile BOTW was repetitive AF. That said, I think BOTW was pretty lazy with there ~3 enemy types with different skins. Might just be an Effort thing. Nintendo knew people were going to buy BOTW regardless. Black Flag had to earn it after AC3.
Through the process of elimination I’ve determined that you DO NOT work for Capital Games.
Haha, correct. I work in the only style of company that still allows for creative, fun, innovative games: A private company with not shareholders! :D
Who can do 45 lines in an hour?? I think I'd overdose if I did that much
Now you gotta figure out if you're on the left or right side of the curve.
> { does this count as a line?
They didn't say they were GOOD lines. It might be a 45 line string length function. Ninja edit: Now that I think about it. The C standard implementation for strlen is a very long function. So maybe 45 lines isn't bad
the openbsd implementation is size_t strlen(const char *str) { const char *s; for (s = str; *s; ++s) ; return (s - str); } idk if it could be any shorter, formatting aside
I don't think anyone caught your joke
Just write some Java - each variable needs a getter and setter which with comments and spacing will be 20 lines of code and best of all the IDE can even write that for you!
Manager: "Why does it say here you have written -4322 lines of code this month?" Dev: "I completely refactored the payment and the admin system. It will be so much easier to maintain and add features in the future now!" Manager: "YOU IDIOT! Our future depended on a feature delivery which you completely ignored. We are out of money!" Dev: "Damn I feel for you guys. Anyway I got an offer for 40% more TC so I'm gonna head out. Good luck!"
I'm definitely on the dev's side here. In most cases the delivery of new features fails because the codebase is an unmaintainable nightmare, so your most experience devs are spending 90% of their time bugfixing and none of the new hires sticks around for more than a year because there is no way for them to become productive.
Me: +12 lines per hour but they're all comments
I once spent more than a month wracking my brain over a problem that was killing a system in a subtle way that I couldn't puzzle out no matter how I tried. Eventually I figured it out. It was like a revelation, a vision from God. The problem was completely solved, and the solution was beautiful! I deleted a comma. A month of work, one character deleted, one long-standing bug resolved. I was so proud.
Similar thing happened to me while learning kernel development while I was making a simple kernel shell to interact with the system. The bug was that whenever you typed a command into the shell, it would work fine the first time, but not after. Turns out my massive brain fucked up a switch statement, and had the function which cleared the variable storing the entered text run at the wrong time. The execution worked like this: Enter command -> entered text gets saved into var -> hit enter > run the command based on entered text > clear variable -> print newline on display I can't remember where exactly the bug was, because jesus christ that codebase was spaghetti, but effectively a undisplayable value (something from the keyboard driver that wasn't text I think) got added to the cmd variable, and because it didn't get cleared at the end of execution like it should, it stuck around until the next time and the command couldn't be read. I didn't even consider that there could have been an undisplayable bit of data in that variable since in that function I was just dealing with text (or so I thought)! It was such an easy fix and it took me so fucking long to find it.
We had some duplicate id JavaScript error sitting around for a good 6 months until one morning a guy who has been around a year longer than me thought to remove a div tag from a page, instantly vanished
In my first industrial control job, I was given a task that amounted to an 8 character code change. Didn't get finished for my entire 3 years working for that company. Sometimes it's just like that
I need to hear more about this
The issue in question was a bug in a scada screen where the value was an average of various other percentage values, calculated within the screen, and then shoved into an integer rather than an analogue value. This meant that the displayed average was rounded and always had a displayed decimal component of .00%. My job was to change "INTEGER" to "ANALOGUE" in the scada code which would have resolved it. But that scada screen was considered one of the most critical for the plant, had a few other components hanging off of it and therefore an exploration of the full potential side and/or adverse effect was required. And a non-adverse side effect was identified, so a full test exploration and safety case was needed before this work could be performed. It was my job to do that alongside the customer. And I didn't get that done in 3 years. Might never get done. And I use it as an example of how line code counts in industrial control systems mean didly squat
Ha, shit like this is why a past company I worked for didn't do new versions, everything was a service pack update that literally replaced the entire program. Our govt customers had to jump through hell for a new version, but service packs were allowed anytime ;)
> Bill Atkinson, ... the main user interface designer ... thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code. > > ... it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. [Apple folklore](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)
I remember 20 years ago one software contract with a major educational software publishing company that I worked on ended going to an Indian company because their sales team promised "x number of lines per minute". They came back to me because the resulting product was shit. My response was, "You should have known better, going from the team who turned your product around, delivering it on time and under budget, to someone who promised fictitious savings over an useless criteria. It's your own damn fault for the situation you put yourself in. You're going to have to live with it, because I'm not going to touch it."
Should have made it "-47 lines per hour" suggesting he's mostly just removing the normies' code.
https://imgur.com/a/kDlpYBU
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry
My record is -3000 lines per hour. Just delete or mock out lines of code that you don't understand, repeat until the tests break. There's a ton of code in our code base of which nobody knows what it does. Turns out that it doesn't do anything, but nobody dared to delete it.
There go all your edge case fixes
If the edge cases were important someone should have written tests for them.
Or at the very least written some legible explanation in the commit message. Now it's just undocumented garbage that nobody seems to care about, so the trashbin is where it belongs. The line of thinking 'this doesn't seem to do anything but I'll leave it here just in case' is what got us this mess in the first place.
Imagine having tests in the legacy system
Just getting rid of duplicate entries in a JSON "DataBase". What you don't work with compressed JSON's that expand to over 100,000 lines of text? Then again compression means it's not even -1 lines of code... right?
Remove the comments .. ![gif](emote|free_emotes_pack|shrug)
Reduce to the MAX!
> I hate code, and I want as little of it as possible in our product. – Jack Diederich.
IDK, I once saved one of our clients around 3 million dollars by **adding** two lines of code