HackerTrans
TopNewTrendsCommentsPastAskShowJobs

alex-nt

no profile record

comments

alex-nt
·5 miesięcy temu·discuss
> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint.

> At the macro level we spend a great deal of time designing, estimating and planning out projects, to ensure that our expensive coding time is spent as efficiently as possible. Product feature ideas are evaluated in terms of how much value they can provide in exchange for that time - a feature needs to earn its development costs many times over to be worthwhile!

Maybe I am spending my life working at the wrong corporations (not FAANG/direct tech related), but that doesn't match at all my experience. The `design` phase was reduced to something more akin to a sketch in order to get faster iterating products. Obviously that now, as you create and debate over more iterations, the time for writing code is increased (as you built more stuff that is discarded). What is that discarded time used for? Well, it's the way new people learn the system/business domain. It's how we build the knowledge to support the product in production. It's how the business learns what are the limits/features, why they are there, what they can offer, what they must ask the regulators etc.

Realistically, if you only count the time required to develop the feature as described, is basically nothing. Most of the time is spent on edge-cases that are not written anywhere. You start coding something and 15m in you discover 5-10 cases not handled in any way. You ask business people, they ask other people. You start checking regulation docs/examples, etc. etc. Maybe there are no docs available, so you just push a version, and test if you assumptions are correct (most likely not...so go again and again). At the end of this process everyone gains a better understanding on how the business works, why, and what you can further improve.

Can AI speedrun this? Sure, but then how will all the people around gain the knowledge required to advance things? We learn through trial and error. Previously this was a shared experience for everyone in the business, now it becomes more and more a solitary experience of just speaking with AI.
alex-nt
·9 miesięcy temu·discuss
There are places that offer Copilot to any team that wants it, and then behind the scenes they informed their managers that if the team (1+ persons) adopts it they will have to shed 10%+ human capacity (lose a person, move a person, fire a person) in the upcoming quarters next year.
alex-nt
·2 lata temu·discuss
I've been working with Java for the last decade and for the past 5Y used the latest LTS versions in a very regulated environment (we have very strict patch deadlines for most CVEs). Rarely we hit issues with migrating to different versions of our dependencies. The most painful one was a small API change in Spring that revealed that we were doing something very bad so it took me 1-2D in between meetings to investigate. It is true though that every few weeks we are hit by a new CVE and we have to patch a lib version, but TBH this is what I expect from a language that has so many eyes on it's ecosystem.
alex-nt
·2 lata temu·discuss
It's never that simple. There is a strong herd mentality in the business space. Just yesterday I've been in a presentation from the risk department and they described the motives around choosing a specific security product as `safe choice, because a lot of other companies use it in our space, so regulator can't complain`...the whole decision structure boiled down to: `I don't want to do extra work to check the other options, we go with whatever the herd chooses`. Its terrifying to hear this...