11–20 of 60 posts
Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful.
It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar.
Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideology.
I have an engineer on my team that's always asking "what if this or that happens in the future?" to which I've started to reply "what if it does NOT?" I know, I know... wow. Not much insightful. But for some reason with this particular engineer this is the starting point to talk about actual requirements. This question in particular triggers the conversation of going back to product to figure out what they truly know…
The question “what if it happens” is important but useless without “how likely is that to happen” and “if it will happen how much time we need to cover for it”
When people argue about the rigor of software engineering (i.e. "is it really engineering?") they often forget an important part: we are doomed to repeat mistakes or reinvent the wheel because nobody ever reads the existing research, nobody learns from the past, we're always blogging about the trendy latest thing withour asking ourselves "maybe someone in the 70s already explored this and drew valuable lessons?".
I find that strong typing often obviates the need for unit tests. Software breaks when data transforms in a way that typing can't solve. When data goes across a wire, or into a database, it leaves your space. Anything you do to your code risks breaking it. Integration tests solve that, but at a very high cost. I don't have a great solution for that. It just comes down to experience: how do things change over time? Yo…
We've come full circle with coworkers telling me that "the best thing" about LLMs is that they can tell you when you have a typo in your function invocation or you forgot a mandatory parameter. This always leaves me dumbfounded, mouth open. If only we had a system to prevent this, from before LLMs!
It's all pretty solid except for the part about OO. Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful. It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar. Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideolog…
we always start with inheritance (Car is subtype of Vehicle; Cat is subtype of Animal).
we need to teach encapsulation as the primary use for OO.
ime, the most effective way of using "OO" in practice is that you define data classes for different entities and then affix a few fancy constructors that let you build entities out of other entities. inheritance rarely gets used.
I have an engineer on my team that's always asking "what if this or that happens in the future?" to which I've started to reply "what if it does NOT?" I know, I know... wow. Not much insightful. But for some reason with this particular engineer this is the starting point to talk about actual requirements. This question in particular triggers the conversation of going back to product to figure out what they truly know…
I find that strong typing often obviates the need for unit tests. Software breaks when data transforms in a way that typing can't solve. When data goes across a wire, or into a database, it leaves your space. Anything you do to your code risks breaking it. Integration tests solve that, but at a very high cost. I don't have a great solution for that. It just comes down to experience: how do things change over time? Yo…
Do languages like Java have strong typing?
I thought so, but I can’t reconcile that with the belief that unit tests in Java would be unnecessary.
> We're not here to write code, but to solve problems. In my opinion having had multiple technical job roles (car stereo/alarm installer, website builder, military officer, CEO, CTO etc…) this is always the job. The job is *always* to make the organization more effective and efficient full stop. Your role in that is what you choose and negotiate with your team throughout your life; boundaries change pre/during/post e…
In most companies your job is to solve tickets. And the only creative freedom a developer has is how that ticket is solved. Quick fix, properly done, rework etc. Maybe that’s why certain smart developers over engineer, because that’s the only place they can create ownership
It's all pretty solid except for the part about OO. Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful. It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar. Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideolog…
i've been beating the drum for a long time that we teach OO programming wrong. we always start with inheritance (Car is subtype of Vehicle; Cat is subtype of Animal). we need to teach encapsulation as the primary use for OO. ime, the most effective way of using "OO" in practice is that you define data classes for different entities and then affix a few fancy constructors that let you build entities out of other entit…
Earlier quoted context omitted.
The question “what if it happens” is important but useless without “how likely is that to happen” and “if it will happen how much time we need to cover for it”
Agreed. This is well studied in software engineering though, I think I've read papers from the 70s/80s addressing this about risk mitigation: what is the impact of the risk if it materializes vs how likely it is to materialize? When people argue about the rigor of software engineering (i.e. "is it really engineering?") they often forget an important part: we are doomed to repeat mistakes or reinvent the wheel because…
We do. There’s dozens of us!
Here’s the thing though, the number of programmers in the world has been doubling every 5 years or so for the past few decades. If you have been doing this for 5 years, you have more experience than half the industry. It’s a young field and information only propagates so fast. You too have the power to help it spread.
I find that strong typing often obviates the need for unit tests. Software breaks when data transforms in a way that typing can't solve. When data goes across a wire, or into a database, it leaves your space. Anything you do to your code risks breaking it. Integration tests solve that, but at a very high cost. I don't have a great solution for that. It just comes down to experience: how do things change over time? Yo…
Can you expand? Because my experience is they are totally orthogonal.
For me, unit testing is to ensure the function's algorithm is correct. You verify add(2, 3) == 5 and add(1, 2, 3) == 6 and add(2, Null) == Null.
But you don't generally write unit tests that tests how a function behaves when you pass an unexpected type. Nobody in my experience is testing add("a", FooObject) for a function only meant to take ints or floats, to make sure it only takes ints or floats.
So they solve entirely different problems: strong typing ensures a caller provides compatible data, while unit tests ensure a callee produces correct results (not just correctly typed results) from that data. You want both, ideally.