My experience is not much different then what you listed, except I discussed programming with my math teacher. She said as long as I was the one who programmed it, and that I didn’t share the program with anyone else, the I could use it.
Looking back on that experience, I’m very grateful to her, but she also probably didn’t realize I was programming it to also show the individual ‘steps’ to get the solution instead of just the solution.
I’ve seen another pattern, I call it “The Document Mongerer”:
I regularly work in a largish monolith. We have micro services too, but most things are in the monolith. Over the years there have been multiple pushes to split it up into micro services. These efforts invariably fail because the _goal_ is the micro service architecture itself instead of something useful to the company, like the ability to do fast releases or better organized code.
Anyways, in the past few months I’ve seen multiple people individually ‘attack’ this insane goal with AI. The first step is always to generate massive amounts of documentation describing the current state of code and proposing areas to split up. Then, after the engineer generates this huge store of documents, they say ‘looked what I created’ and then drop it and move on to some other shiny toy. No one will ever read these documents. They are out of date before they ever get ‘completed’, their sole usage is to waste credits.
I’m seeing big wins with AI, but not at the product level. I’m excited about the progress, though maybe I should be questioning our priorities more.
There is so much hype around AI and using it to move faster that the extreme focus on ‘product’ and prioritizing ‘impact’ has greatly relaxed.
For the first time in my entire career, I’m able to prioritize addressing technical debt and friction in our SDLC processes.
Normally, these types of changes get bundled in with regular product work and cause timelines to grow. Nobody paid down technical debt unless it came due and was no longer optional.
I am using AI to address tech debt, but these are all things I identified as problems - and big improvements - long before AI was a regular tool in the toolbox. I just could never demonstrate how addressing them early would pay off in the long run through faster project turnaround. Fixing known issues simply doesn’t rank against new features when it comes to prioritization.
Anyway, I’m thankful to finally get to fix these things, and our ticket-to-deployment time is going way down - but none of this matters if ‘product’ doesn’t streamline their goals and priorities as well.
Similar here, the issue that I'm having a hard time getting across to leadership is: internal users and customers do not want so much change thrown at them. Totally get the 2 person startup thing trying to build something greenfield first time, big hurry, etc. That does not translate to what companies with existing customers and not scrambling for product market fit need though.
My kids are young enough that I don’t need to worry about it yet, but I can totally see how I might have the same issue. Beyond just myself, my partner is just as invested in the kids and I can foresee needing to rediscover ourselves together. Do you have any advice, tips, or insights for new empty nesters?
No, unfortunately this has been extremely difficult in my life. With raising children you have a shared goal and in although its hard it makes life simpler in you have something meaningful to focus on. Without kids we have had to face our own emotional issues and dynamics and this has not been easy.
Not really. I can say though that it is true—my wife and I suddenly can enjoy just the two of us gong out to dinner on a Friday night again.
It's hard trying to remember what it was we did before the kids. In some ways it doesn't matter though—we're both a lot older and we probably would not do many of the same things.
We've also at this point spent decades together, working together on the family. It's nice to just work on an electronics project. And I think my wife is happy to go knit or make a quilt. So we do out own things—just across the room from each other.
I’ve seen this too, but mostly with the ‘team lead’ seniors- the ones interested in the management track.
On the other hand, a SE2 was asking me for help with something that was way off track from what they should have been doing. This isn’t a new SE2, but someone who seems the have topped out as an SE2. Anyways, they were not understanding anything I was pointing them towards, so I got frustrated and just gave them the exact prompt to feed into their AI. The AI fixed it for them. They were amazed by the result, but should have been horrified by their uselessness instead.
> Asking me to open a new issue to discuss this behavior instead of it being a high priority for them to open up a new issue internally to fix this is odd. I'm not here to do their homework for them.
Why are people so entitled? How much is the author paying WolfSSL to make demands of them?
> Currently I've only identified one victim of this decision, but there's bound to be more out there.
Oh yes, he has become a victim of using a FOSS library.
I don’t think it was clear, but thanks for the insight.
Was WolfSSL forced upon Elixir or Erlang? Did they purchase it and received a defective product? Are they held hostage by WolfSSL’s decisions? Are they not allowed to modify WolfSSL as needed themselves?
I fail to see any victims beyond perhaps the WolfSSL maintainers for having to suffer such entitlement.
The lib is (AIUI) a client library, meaning that it will fail to communicate with an HTTPS-enabled, WolfSSL) server, ostensibly because the WolfSSL isn’t SOEC-compliant.
You explicitly modeled the situation so that no victims can exist, so please do spare people from the autofellatious poetic questions and remarks about how you fail to see any victims.
> Was WolfSSL forced upon Elixir or Erlang?
Yes actually, and upon others, that's how computer networking works. Did you read the blogpost by the way? Even just the beginning? Really doesn't seem like it.
Hint: there's a reason the word "middlebox" is mentioned 16 times in there, and that the word "server" is mentioned another 6 more.
> Did they purchase it and received a defective product?
They did not purchase a copy, WolfSSL distributed them one for free. The blogpost author did identify the product as defective however, as it allows for and defaults to spec-noncompliant behavior. It stands to reason that this then affects WolfSSL's paying customers (and their downstream customers) too, who might be unknowingly operating or interacting with spec-noncompliant services as a result.
Will people need to read out the whole article for you?
> Are they held hostage by WolfSSL’s decisions?
Yes, and so are others, that's (still) how computer networking works.
> Are they not allowed to modify WolfSSL as needed themselves?
What would they do with it? Put it on a USB stick and stick it up their ass?
> for having to suffer such entitlement
Are you really one to take issue with another person's behavior after this power tantrum?
Neither person is entitled to the work of the other and neither wants to do the work which seems to be how we ended up here. The author can't make demands of the project and so wrote a blog post warning others that it's not production ready and you'll have broken software if you use it. Their conclusion isn't that they must fix it but that you should use a more mature library.
Two adults both defected in the social prisoner's dilemma and so here we are. Both individuals believing to have done free labor for the other and that they should be grateful.
> Our priorities are clear: availability first, then capacity, then new features.
Let’s see how long it takes them to turn this ship around.
reply