And notepad++ had no easy way of showing trailing whitespace. So every commit was a dance of commit -> read rejection log -> remove trailing whitespace -> commit again.
You should worry more about how things are named, the number of abstractions used, and whether the code has any comments explaining the writer’s intent.
Just have an options file which is checked in with the code and enforce whatever is set in there works much better. You still avoids all the useless discussions about formatting while also allowing to set sensible settings which are consistent with surrounding technology.
* All our code must be linted / formatted
* All their code must be ignored.
(I wish I made it up. This was what a CTO at a previous project did. 30-odd people were waiting and churning on while he was unavailable because he had to indulge his own things. And once they were beyond the point of no return, both he and the manager that greenlit this project quit, but stayed on as independent contractors. I believe they were demoted or taken off the project and eventually gotten rid of when a new manager was found)
I don't think that business logic is dry per se. The problem in my opinion rather is that in other parts of the software project, there is much more openness with respect to
- trying out new things in new ways
- making the code more elegant
- seeking abstractions
- ...
than in the business logic area.
Believe me: for the kind of business logic that I see at work, I could immediately see ways in which the (non-trivial) business logic could be made much more elegant by using clever mathematical ideas, but suggesting such ideas to other colleagues or the bosses is like talking to a brick wall.
Debugging is twice as hard as
writing the code in the first place.
Therefore, if you write the code
as cleverly as possible,
you are, by definition,
not smart enough to debug it.
-- Brian KernighanRecursive descent, flex/bison, parser combinators… these are the tools to manage complexity. This is why lispers go so nuts once it fully dawns on them the power of manipulating the AST along with any other data structures in the program… it’s just a shame about all those parens!
We’re not writing machine code, most are not writing assembly or even C or Rust. Most hit the memory managed languages and it seems our abstraction has stalled, with endless language features applied to our current layer of abstraction. Its like goto programming before better abstractions were discovered.
This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.
Believing such implies it’s more difficult to ride in an aircraft craft around the world than legitimately beat Magnus Carlsen in a rapid chess game.
The reverse is frequently the case where running a marathon faster is more difficult than doing so slower.
Reread my post. I literally said neither definition is absolutely true.
Further the quote wasn’t suggesting equivalency. Rather intelligence as one bound on debugging, which is clearly true as can’t get a flatworm to do it. When trying to debug really clever code the easiest solution can be giving up and starting from scratch.
Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence. A harder bug often needs more time to solve. This is common sense.
You're just sinking with the ship now.
This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty.
>Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence.
False, you clearly missed me stating it intelligence was “one” limitation not the only limitation. Poor tooling can be a massive pain among many other things. Again though this is talking about debugging a very specific kind of unnecessarily complex code.
It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily.
>False, you clearly missed me stating it intelligence was “one” limitation not the only limitation. Poor tooling can be a massive pain among many other things. Again though this is talking about debugging a very specific kind of unnecessarily complex code.
The quote was suggesting absolutism one limitation. By showing the existence of an equivalency I've shown the quote is not absolute. Therefore the quote is not intelligent. Therefore your statement is false and nonsensical.
Luck wildly impacts how long ‘difficult’ problems take to solve. I’ve solved bugs in seconds someone literally spent weeks and asked multiple people to help them solve and I’ve had the same thing happen to me.
Thus actual solve time and absolute difficulty are almost orthogonal.
> The quote was suggesting absolutism one limitation. By showing the existence of an equivalency I've shown the quote is not absolute. Therefore the quote is not intelligent. Therefore your statement is false and nonsensical.
Again no, it was saying one limitation becomes significant in a specific situation. Often these bugs may not actually take long to fix, but you’ll suffer when dealing with them. Even strait forward off by one errors can be annoying when you have to reason about really tricky bits of code.
That feeling where you spend an hour staring at an IDE with absolutely no clue what’s going on sucks even if it doesn’t take that long to actually fix the issue.
No it just means luck is another factor. You have luck, intelligence and length of time. Time is correlated with possibility right? You can get lucky and guess the probability on the get go.
Either way you introduced a third possibility here which goes further to illustrate that this quotation is inaccurate and not intelligent.
>Again no, it was saying one limitation becomes significant in a specific situation. Often these bugs may not actually take long to fix, but you’ll suffer when dealing with them. Even strait forward off by one errors can be annoying when you have to reason about really tricky bits of code.
False. You are absolutely wrong. The statement was made without qualification to a specific situation. Therefore it is made in the context of the universal situation meaning absolutist. Sinking with the ship again.
>That feeling where you spend an hour staring at an IDE with absolutely no clue what’s going on sucks even if it doesn’t take that long to actually fix the issue.
So? This doesn't have anything to do with the topic at hand. The topic at hand is the quotation is wrong. How you feel during debugging is off topic.
The overall stamens includes an “if you” which is a qualifier. So you seemingly don’t understand what those words mean and objectively wrong here.
He is saying if you write code as cleverly as possible then in ALL situations it will be impossible to debug by you, which is false. The quote is not intelligent.
You know all of this you're just sinking with the ship and trying to manipulate the situation your way while throwing insults at me on my ability to understand language. Insults are a signature move by someone who has clearly lost the discussion and you've lost definitively.
I think we're both done here. After that insult there is no further need to continue the conversation. Please leave.
And no it’s not saying in ALL situations you can’t solve ANY bugs. You only finish debugging when you solve every bug not just 1 of them. Further sometimes you’re going to write a clever bit of code that doesn’t contain a bug and thus doesn’t need to be debugged.
So it’s saying writing buggy code is easier than correct code, so avoid writing clever code or some of it is going to stay buggy. That’s what the quote actually means.
PS: Also, that wasn’t an insult it’s a statement of fact. You’re trying to twist the statement as not being qualified but it’s got a qualifier.
You're a liar. I clearly am typing english and reading your responses. You're typing to me in english so you know I understand it. What you said was therefore with 100% intent malice because it's simply not true. You are not a moral person. You're just an asshole and you know it. THIS statement can be claimed to be a fact, not yours, not even in the slightest.
I mean you know what happens when you call a stupid person "stupid" to his face and then say it's a fact? It's not an insult? Just a fact? You know this. No need to spell it out. You're an ass hole.
>Nope, nobody writes every single line of code in a program as cleverly as possible attempting to do so generally means you don’t finish.
You're just making stuff up at this point. A quotation made around a situation that can never occur according to you? You're just lying now.
>And no it’s not saying in ALL situations you can’t solve ANY bugs. You only finish debugging when you solve every bug not just 1 of them. Further sometimes you’re going to write a clever bit of code that doesn’t contain a bug and thus doesn’t need to be debugged.
No you're just adjusting the meaning to fit your agenda. You're going at a bit of of a stretch here. This conversation has descended into way to deep of pedantism thanks to your attempt to twist things in your favor.
>So it’s saying writing buggy code is easier than correct code, so avoid writing clever code or some of it is going to stay buggy. That’s what the quote actually means.
No. It's simplistic to say that clever code tends to be buggier. This guy took the extra step to say that clever code is "by definition" not debuggable. Again twisting the situation to fit your agenda.
Man you're done. You need to stop with the insults and stop with these pathetic attempts at explaining your point of view.
Ignorance doesn’t mean stupidity it means you don’t understand something. It’s possible to gain understanding when you accept you’re wrong and try and learn, but lashing out means you will forever wallow in ignorance.
> generally means
“can never occur” this this is why you don’t understand. You need to actually read what was written not whatever nonsense comes into your head.
You only need to debug code that’s not correct. Therefore logically when talking about the effort to write code vs debug that code they don’t mean the effort to write correct code vs debut correct code. Instead it’s the effort to create incorrect code vs debut that incorrect code. Any other interpretation is nonsense.
Know plenty of people who call this job security
I just had a junior dev rewrite some of my code so that: a builder calls a constructor which instantiates a builder factory which builds a builder then that second builder creates the object.
This whole system only builds one type of object. He thinks that his solution is better because it’s more extensible.
I can’t make him see why it’s bad.
> I can’t make him see why it’s bad.
Schools teach OOP as though adding new types of objects is the norm—like every type of software construct is actually a GUI widget in disguise and we're going to be adding new interoperable subclasses every other week, so we may as well get the infrastructure set up to make that easy.
In most real world applications, the only type of object that behaves that way is, well, GUI widgets. Nearly every other type of construct in a typical system will have at most one implementation at a time (possibly two during a gradual transition). Factories, builders, and the whole design pattern menagerie aren't particularly useful when for the bulk of a system's life they're all just proxies to a single constructor.
I don't know if there's a good way to teach this out of someone besides just letting them experience it, but that's the insight that he needs—different types of code have different maintenance characteristics, and the tools he's been given were developed for a very specific type of code and don't apply here.
Software development is reliant on self-learning, but still, some education can be outright damaging.
[0] https://www.dataorienteddesign.com/dodbook/
[1] For instance, objects in OOP are typically bundled with other data related to the object. As an example, in OOP a Door object could have float X,Y,Z coordinates, an enum for type of door it is, a bool for opened or close etc. This leads to inefficiencies in cpu cache usage when you are iterating through a list of doors and not using every field of the door object.
See this GDC talk for why this matters in the gaming world: https://www.gdcvault.com/play/1022248/SIMD-at-Insomniac-Game...
Experience did the same for me.
It just takes some time.
I got a call from a guy saying "hey, this broke". I had not touched this system in 13 years. I had to re-remember a bunch of stuff. Some of the code was still a joy to work with. The parts that were hard were... obvious, and even then, I remember cutting corners, not documenting stuff, and overcomplicating things "just in case" (which mostly never happened).
There's little amount of someone 'telling' me ahead of time how much difficulty I was leaving for the next person (or even myself). It really seems like the only way to get this experience is with time. That doesn't mean you can't follow some best practices that turn out to be beneficial. But until you've experienced the downsides, you won't really be able to internalize the why regarding something being good or bad.
If you can easily read and understand some code, then it’s good code and you should leave it alone.
Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply!
Now, that doesn't mean that you need to built everything bare bones without the help of any third party software - just make sensible choices. Unfortunately, developers are way too prone to add another shiny thing to the mix.
So here's how you decide if you really need something:
At first: You don't - continue as is.
Then: If the problem persists and the suggested solution keeps coming up, still refuse, but investigate the solution.
At last: If the problem persists, the solution seems well suited to address it and it keeps coming up - accept that you have the problem and adopt the solution.