291–300 of 361 posts
To follow advice #6: If you need the horror story to understand, look up "Thrombosis".
Earlier quoted context omitted.
I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature products, which almost always have some history behind them: shifting requirements, "seemed like a good idea at the time, but with the experience we have now it probably wasn't", shifting trends in the industry, constraints in terms of dev time or budget, etc. Ofte…
A balancing act between premature optimisation and technical debt.
Most of the time, just do "the simplest thing that will work" is actually quite future-proof, because when (if!) it needs changing then this is usually not too hard, because it's simple. It's usually not too tricky to make something simple more complex, and the extra costs over "make it complex from the start" should be quite low.
What I do see is people just writing bad code. "zomg this function is 5,000 lines long and nested 9 levels and I can't make head or tails of it, but somehow it magically works, kind-of, with bugs, but no one really dares to touch or refactor it because the last two times we introduced regressions and had to scramble a fix and there are no tests, and adding tests is hard and requires refactoring which we don't dare". That type of stuff. Not an hypothetical exaggeration either I'm afraid :-(
But bad code is just ... bad code. People call this "tech debt" but it's not – it's just bad code. Probably took more and not less time to get that crap to work in the first place compared to if you had done it right.
I think one of the major mistakes the Right Way Guys make is to "solve" this by adding patterns and architectures and whatnot. But the solution is to just not have bad code like this.
I've seen all of the above play out more than once, with different companies with wildly different tech stacks.
Earlier quoted context omitted.
Entities in game systems tend to behave like that too when the whole thing is under development - but then (a) arguably a monster chasing you around is just a special GUI widget with extra behaviour and hit points; and (b) when things get really complex it doesn't hurt to switch from OOP to ECS for games.
I don't have a lot of knowledge on ECS, are there any good articles out there that compare it to OOP?
[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...
Despite reading essays of other devs telling you how you should dev, have faith in yourself. Over time you'll develop your own proclivities, instincts, etc., and end up writing your own essays to the next generation. People writing essays are not writing it from some impossible point of knowledge or privilege. They're just you in the future.
You don’t need formal training, or “experts” writing blog posts, or the latest fad technology. Gusto and gusto alone can make you successful.
Earlier quoted context omitted.
> it's limited in that you can't bring it all the places that you can bring your eyes. Why can't you? > Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can. This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in t…
> Why can't you? Honestly not trying to be rude, but that would be because of how eyes work. The moment you do anything that goes beyond looking at code, is the moment you've met that limitation I described above. The other part you brought is totally valid, it's just all about tradeoffs. If you prefer using a debugger in situations where I would read the code, then more power to you. Actually, it's funny, because th…
I like your call-out of the "one true way" section. What I was thinking in that section is that my experience, having now traversed a number of "one true ways", is that: 1. Very nearly all tools and techniques are truly useful in some way in some circumstance, and 2. Not all "one true ways" are created equal; some tools and techniques are more useful than others and better stand the test of time.
In my view, using a debugger to understand the runtime state while reading and exercising code (especially when it is unfamiliar) is one of those techniques that is broadly useful and never out of date. But that's not a totalizing view, it isn't the "one true way", obviously nobody only reads code while running it within a debugger, nor should they! But dismissing its utility for this use case of understanding code more deeply is, in my view, just odd.
Earlier quoted context omitted.
Arguably, biochem also has "solid foundations" in physics. Would you recommend someone in your field to "follow the physics" in their journey?
Yes. Also follow the chemistry, and follow the maths. Any answer other than "yes" falls squarely in the anti-intellectual category... But of course all the usual pragmatism applies unless you are a point particle having indefinite lifespan.
That sounds like by "follow" you don't mean "study a lot"... What do you mean then?
1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. 2. The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bull…
I don't know why you're getting so many down votes here. What you say is unpleasant but it's all true.
Earlier quoted context omitted.
You had me at numerical algorithms but I'm not sure I agree about functional programming and type theory. I used to like functional programming and type theory when I was younger and found it completely useless as I moved further along in my career. I'll make a different suggestion: set theory (which builds intuition around relational data modeling) and distributed systems (which builds intuition around building scal…
I don't want to be dismissive of set theory, because it has an extremely rich History and is still seen by most as the foundation of maths, but I believe there are some fundamental issues with it that make type theory a more appropriate foundational choice for general computation and programming language theory/design. There's a reason theorem assistants and proof languages are based on some version of type theory, r…
Most of the volume of useful work to be done in programming is about state manipulation, which is mostly relational database operations, which is mostly about set theory.
I think every engineer should learn foundations that best equip them for the market long term, and prioritize their order of attack along those investments which will earn them outsized value. Data structures and algorithms, set theory and distributed systems equip an engineer extremely well for that.
I have a very hard time believing deep investments in functional programming and type theory would differentially pay off better.
Now, if one's goal is not to optimize for the market, then I think the answer is a lot more broad.
1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. 2. The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bull…
> 1. Software does not make money. Not ever. Software creates value that you can exchange or rent in exchange for money. All the big software companies know this, their software developers know this, and that's why those developers are well compensated.
Tools unlock valuable opportunities and this becomes more true with superior technology. The opportunity for accessing value is not profit though. Profit only occurs when income exceeds expenses. The means to access income still costs money, such as Customer Acquisition Cost, whether those means are things like better tools or advertising. Superior software may reduce the time per customer transaction, cost per customer transaction, or increase the number of simultaneous transactions but its still those transactions that drive profit. The software is just a contributing artifact. Most of those transactions probably cannot occur without the help of some software, but without the business transactions the software is just an expense not making money.
Very good article and I hope more people read it. Over my career of 15 years in software (data management), I have learned exactly that. One other thing that really helped me was something that I learned in my Theravada Buddhist upbringing: https://en.wikipedia.org/wiki/Kesamutti_Sutta > The Kesamutti Sutta states (Pali expression in parentheses):[5] Do not go upon what has been acquired by repeated hearing (anussava…
I have a hard time understanding what you mean by that, could you put it in simpler terms?
"Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations.
But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it."