Author: github.com/louthy/language-ext
* blog: paullouth.com
* bluesky: @paullouth.bsky.social
* mastodo: 4four.org/@louthy
- > There's considerable evidence
Yet you provide none.
- People with mental health issues need help and support. Just because there’s a pithy saying, doesn’t make it universally beneficial to have suffered hardship.
Not sure what else you’re expecting? I’m not advocating imposed hardship, just trying to give some context for why it can often lead to a more robust and driven person. It’s clearly not universally true.
I imagine there are lots of veterans that are able to cope and have become more robust. But there will always be mental health aftershocks, because that’s why it was a hardship in the first place.
- As someone who has had some serious hardship and is certainly more resilient because of it, I can also confirm the mental scarring that comes as ‘part of the package’.
I think to an extent the mental impact of it is a necessary evil. The future resilience manifests as a drive to not find yourself in the same (or an equally difficult) position again — because it’s so emotionally devastating — so you fight harder to not allow it to happen again. This makes a person more driven in general.
Another aspect is that you’ve seen how ‘deep’ an emotion can be (traumatic) and so more ‘everyday’ emotional events can seem much more trivial, making them easier to deal with. Although, it can sometimes leave the person seeming ‘cold’ emotionally. One thing I found was I was less tolerant of people without the level of resilience I had, which I had to work on.
Of course, there will be some people that can’t endure the initial hardship and don’t develop that resilience. My impression is that most people do endure and find a way to come out of the other side, like a basic survival instinct, although that’s purely anecdotal.
- It isn't about a particular time in history, it's about the individual. An individual who suffers hardships often has to endure to overcome said hardships. That makes the individual more resilient and more able to deal with future hardships.
I think the phrasing can come across as a bit macho, which I don't think is the point. It's about resilience.
- > cancelling Amazon Prime at first, but realized I didn't -really- need some JIXFOZ branded gadgets next day, after all.
The problem with cancelling Prime is the unrelenting haranguing to re-sign up and the clearly punitive delivery charges. You get adverts from cancelling due to adverts and end up paying more.
I’ve just started to focus my purchases at specialist UK stores, rather than defaulting to Amazon for everything.
- > If your protection is to "understand the implementation" it means buggy code.
Hilarious. Understanding the code is literally the most important thing. If you don't understand the code then you can't understand any unit tests you write either. How could you possibly claim test coverage for something you don't understand?
I suspect you primarily develop code with dynamic languages where you're reinventing type-systems day-in day-out to test your code. Personally, I try to minimise the need for unit-tests by using well-defined types and constraints. The type-system is a much better unit-tester than any human with a poor understanding of the code.
- > Either you're a true 100x coder who can get a full understanding of every single project and every effect it will have through the full end to end stack.
It's hard to state how good I am without sounding like an arsehole, so here goes... I am certainly a very experienced engineer, I've coded from the age of 10 and now at 50 I'm 'retired' after selling the company that I founded. I started in the 8bit era doing low level to-the-metal coding and ended it building an internationally used healthcare SaaS app (with a smattering of games engineering in-between). I've been a technical proof-reader for two Manning books, have at least one popular open-source project, and I still write code for fun and am working on my next idea around data-sovereignty in my now infinite free time... so yeah, I'm decent, and I feel like I've gained enough experience to have an opinion on this.
But also you're not reading what I wrote. I never said "a full understanding of every single project and every effect it will have through the full end to end stack", which I explicitly dealt with in my last reply, when I said: "It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important."
If the scope is small, you don't need "a full understanding of every single project and every effect it will have through the full end to end stack". But in terms of what it does touch, yeah you should know it, especially if you want to become a better software engineer, and not just an engineer with the same 1 years worth of experience x 30.
It should also not take "a few days" to investigate the scope. If it's taking you that long then you're not exercising the capability that allows you to navigate around unfamiliar code and understand what it's doing. That knowledge accumulates too, so unless you're working on a completely different project every single day, you're going to get quicker and quicker.
I have seen pathological cases where a dev that worked for me went so far down the rabbit hole that he got nothing done, so it has to be a pragmatic process of discovery. It should entirely depend on the extent to which your change could leak out into other areas of the project. For example, if you had a reusable library that had some core functionality that is used throughout the project and you wanted to change some of its core behaviour, then I'd want to find all of the usages of that library to understand how that change will affect the behaviour (if at all). But equally, if I was updating a UI page or control that has limited tentacles throughout the app, then I'd be quite comfortable not doing a deep dive.
> "here's code that Bob wrote 10 years ago, it's not working. Customers are complaining and this needs to be fixed yesterday".
I've been in that exact situation. You need to make a decision about your career. Are you just going to half-arse the job, or are you going to get better? If you think continuing as you are is good for your career, because you've made your idiot boss happy for 5 minutes before they give you the next unreasonable deadline, then you're wrong.
The fact is the approach you're taking is slower. It's slower because you and the team of engineers you're in (assuming everyone takes the same approach) are accumulating bugs, technical debt, and are not building institutional knowledge. When those bugs need dealing with in the future, or that technical debt causes the application to slow to a crawl, or have some customer-affecting side-effects, then you're going to waste time solving those issues and you're sure as hell gonna want the institutional knowledge to resolve those problems. AI doesn't "understand" in the way you're implying. If it did understand then we wouldn't be needed at all.
> Most likely the fix will work and nobody has to touch that bit in a few years. Should we spend time to understand it fully and document it, add proper and comprehensive tests? Yep. But the bosses will never approve the expense.
So you work for a terrible boss. That doesn't make my argument wrong, that makes your boss wrong. You can obviously see the problem, but instead of doing something about it, you're arguing against good software development methodology. That's odd. You should take umbrage with your boss.
The best engineers I have worked with in my career were the ones that fully understood the code base they were working on.
- > It sounds like you've never worked a job where you aren't just supporting 1 product that you built yourslef
In my 40 years of writing code, I’ve worked on many different code bases and in many different organisations. And I never changed a line of code, deleted code, or added more code unless I could run it in my head and ‘know’ (to the extent that it’s possible) what it will do and how it will interact with the rest of the project. That’s the job.
I’m not against using AI. I use it myself, but if you don’t understand the scope fully, then you can’t possibly validate what the AI is spitting out, you can only hope that it has not fucked up.
Even using AI to write tests will fall short if you can’t tell if the tests are good enough.
For now we still need to be experts. The day we don’t need experts the LLMs should start writing in machine code, not human readable languages
> I do not need to understand the full stack.
Nobody said that. It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important.
Not understanding the thing you’re changing isn’t pragmatism.
- > Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform
Which is why you spend time upfront becoming familiar with whatever it is you need to implement. Otherwise it’s just programming by coincidence [1], which is how amateurs write code.
> and are probably going to even insert more footguns than the AI.
Very unlikely. If I spend time understanding a domain then I tend to make fewer errors when working within that domain.
> At least when the AI does it you can review it.
You can’t review something you don’t understand.
[1] https://dev.to/decoeur_/programming-by-coincidence-dont-do-i...
- > But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation
Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you.
This is ‘phoning it in’, not professional software engineering.
- That’s still a poorly designed system. For UI there should be a ‘view model’ that augments your model, that view model should be able to represent every state your UI can be in, which includes any ‘intermediate’ states. If you don’t do this with a concrete and well constrained model then you’re still doing it, but with arbitrary UI logic, and other ad-hoc state that is much harder to understand and manage.
Ultimately you need to make your own pragmatic decisions about where you think that state should be and how it should be managed. But the ad-hoc approach is more open to inconsistencies and therefore bugs.
- Continuous refactoring is much easier with well constrained data/type schemas. There are fewer edge cases to consider, which means any refactoring or data migration processes are simpler.
The trick is to make the schema represent what you need - right now - and no more. Which is the point of the “Make your invalid states unrepresentable” comment.
- > Hi, can you give an example? Not sure I understand what you're getting at there.
An utterly trivial example is constraining the day-field in a date structure. If your constraint is at the level of the field then it can’t make a decision as to whether 31 is a good day-value or not, but if the constraint is at the record-structure level then it can use the month-value in its predicate and that allows us to constrain the data correctly.
When it comes to schema design it always helps to think about how to ‘step up’ to see if there’s a way of representing a constraint that seems impossible at ‘smaller’ schema units.
- Your example doesn’t validate your point. That’s a valid state made unrepresentable, not an invalid state made unrepresentable. Your example simply demonstrates a poorly architected set of constraints.
The critical thing with state and constraints is knowing at what level the constraint should be. This is what trips up most people, especially when designing relational database schemas.
- *Spender
Auto-complete gets me again.
- Mary Spencer has a great one-take video [1] walking through the song and lyrics, really beautifully done
- You also need a country name with 'Democratic' in it:
Democratic People's Republic of America.
That's how you know it's a fully totalitarian state.
- > “Why functional programming is the future (again) (haskell.org)”
Ouch, that hurts!
Your link to some stats on levels of poppy production does not support your conspiracy theory.