I think it depends on your company rather than saying "most". If you are in a software company (i.e. you sell the software you write), then your value is the unique IP you create from writing code. In that case, hopefully a larger portion of your day is coding.

edit: When I say coding, I don't mean plumbing code, I mean something that is actually a unique invention.

I have delivered successfully projects using Scrum, but we were fortunate that our Scrum Master was well trained and a senior engineer. Our CTO also let us figure things out, and helped us when we were blocked. He was genuinely concerned with the team having a balanced workload, ensured we deliver user value and our software was of high quality. Story points were not used as performance metrics but a tool to help provide stakeholders with some estimation, but only when our velocity became stable. Overall, our process was light-weight, we spent most of our time coding, and we pushed hard to deliver value to the user. If we fell short, we learned from it, no blame, just learned.

Doesn't autoplay for me, maybe I have a different local setting.

Not the linked page (which doesn't say what the product is, which is why I went looking for the home page). Both have a video, but only the home page autoplays.

Chrome on Android.

As a parent, I'm hoping this will reduce the at-home workloads and shift more work towards school. What's the real life value of having students go to school and then spend all-nighters trying to do homework and all the expected extra-curricular?

As I remember my education time from high-school onwards, all-nighters were usually a consequence of slacking off during school time.

In college/university a fairly big part of the education was learning what was compulsory reading and what was optional. There was always more reading than hours in the day.

I wish HN had a central thread feature for discussing oft-debated topics like TDD, microservices, and agile. This way, we could contribute to the conversation instead of constantly rehashing the same points through new posts.

I was genuinely interested in OP's question and was hoping responses would not fallback on the much-already discussed "TDD or not" topic.

This is great! I messed up my ankle when I began taking transit and walking to the office in a pair of terrible dress hoes.

Be curious to know if anyone who has trademark legal knowledge can answer this question. Since the word Impossible is common, as far as I can gather, if it is for a different industry you indeed could use it?

edit: typo

If you are writing code by yourself and your code base is relatively small, then I agree it's hard to see the benefits at first.

If your team and code base grows, one of the first things you'll notice is a lot of time wasted trying to figure out what parameter types a method takes. If you can imagine, a new person onboarding on your code base and having to figure this out constantly and then forgetting, is pretty inefficient.

TypeScript solves that problem since you declare types explicitly in code. The new person will know exactly the parameter types, the IDE can support you more intelligently, and you'll get upfront compile time errors.

The downside is the initial setup and the extra effort of declaring types, so it comes with a cost, but personally I think the benefit outweighs the cost.

IMO every project should be kept as small as possible. Large code bases are anti-patterns. It's almost always desirable to break up functionality into independent modules. If the modules are sufficiently independent (loose coupling), then you won't get into situations such that you constantly need to modify them... Properly designed modules don't need to be changed often. In my own projects, there are many modules which I haven't modified in several years.

"TypeScript is useful for large code bases" is like saying that a truck is useful for carrying boulders up a mountain... Sure it does, but what if you don't actually need to carry boulders up the mountain to begin with?

Maybe then question then is how does one get every developer to design and build modules as you have prescribed? (Recognizing different talent levels across the industry / delivery deadlines). Genuinely curious to know a scalable solution for this.

edit: typo

Agree with this. Ppl can make a mess inside their typesystem specs esp. when making their code interface with others on a large project. Adhoc types that are just bloat. Etc.

Has anyone else had multiple years of experience with typescript in prod or what?

TBH, I feel like the TypeScript movement is driven mostly by junior developers. The software industry has always been like this; young, loud-mouthed junior devs come in thinking that they know better than all the senior people... They ridicule their elders who have an actual proven track record; they then proceed to push their naive ideas on the entire industry... 10 years later they (sometimes) realize how dumb they were (yes, I've been there myself) but by that point, the next, bigger batch of loud junior devs enter the workplace with even dumber ideas and drown out all the wisdom yet again... Again, the juniors with big egos, fresh out of MIT, think they know better than all the old dinosaurs and they perpetually keep destroying every chance of actually moving the industry forward... The cycle repeats over and over.

I agree in general except what you said about MIT ppl. I find them to be the humble ones, ironically.