Hacker News Reader

If Typescript is adding 20% to your workload, I suggest spending a little more time getting used to it. When I first started writing TS, I agree it felt a bit cumbersome and it took some time to understand the nuances, but the time it's saved me in refactoring and catching errors I would have made without it has more than made up for it. I know this isn't really your main point, but I don't want anyone on the fence about TS to be scared off by that 20% figure.

Using static typing on anything takes more time at first, but I agree that it saves time over time.

Everything that you mentioned is supposed to make things easier, safer and more importantly faster to change.

However it seems like developers everywhere are just adding these things because they heard that facebook or whoever was doing it without actually stopping to think if it makes sense for their team and their product. Before you know it you're left with a ball of tool/process mud where every little change requires passing a resolution at the UN to implement and deploy.

They make a lot of technical sense to most teams, not just to Google/Facebook. The problem is that there's a cost to everything but people don't take that into account.

You don't buy a car and say "I want those fancy wheels, yeah!" without considering the cost. But in IT, sure, management thinks most of that is easy or barely costs anything. I think that's the whole point of the article.

I’m now of the opinion that using typescript, react and Webpack every time is the right thing to do! Even for a tiny project.

Typescript has won the well typed JS war and offers the most practical solution. There are Haskellly and Lispy alternatives that are sexier but typescript feels closer to the metal and working with JS interop is sublime while getting the benefits of types for refactoring, documentation and robustness. Always use it.

React is the best front end paradigm. It provides an excellent way to reason about the front end and avoid messy state and event handlers or bindings going around cascading shit into your ui.

Webpack is cool. You’ll need something to bundle and I feel it’s a good choice. I’ve had it singing some interesting tunes! It’s very flexible.

Also git goes without saying. And the other implied tool goes literally without saying :) and not it’s not yarn!

Once you get used to these tools it’s just not worth not using them. It’s a one time investment like learning touch typing.

Yes in js you just need a script tag but most languages and platforms off the web have a bundled/build process, Ui toolkit and typed language so I don’t see the big deal in learning these for web dev.

- Don't default to "Agile" (or be fully "Agile" for that matter)

- Don't default to Typescript (or any technology for that matter)

- Don't default to TDD (or any dev methodology for that matter)

- Don't default to linters and bundlers (or any intricate tooling for that matter)

- Don't default to complicated infrastructure

A friendly PSA that you can still, in the year of our lordt 2019, create a static site with an HTML file deployed to shared hosting over FTP. You could also create a dynamic site with some PHP thrown in there.

Reach for the minimal process, tech, methodology, tools and infrastructure you need to get the next X pieces of work done, and complicate things only if the pros outweigh the cons.

I'm not picking on you specifically blobs, I'm sure you walked into an organization that employed all these things with seemingly no good reason. The thing is, there's always a reason, it just might not be a great one!

That said, if your goal is to estimate things more accurately, you might need to spend a little more time with your coworkers to define as many unknowns as possible.

> A friendly PSA that you can still, in the year of our lordt 2019, create a static site with an HTML file deployed to shared hosting over FTP. You could also create a dynamic site with some PHP thrown in there.

Honestly that sounds like hell, we may live in a spiderweb of complexity but it's still a long way from the primitive web of the 90's which provided every conceivable kind of way to shoot yourself in the foot.

The hidden issue is that new web products are becoming increasingly complex due to tight competition, but businesses somehow do not expect that increased complexity means there is a need for larger teams and budgets. All this cruft in the modern web build pipeline is stuff made by developers, for developers, to help us navigate the impossible tasks handed to us in impossible timeframes. Some of these additions are very welcome, but the proliferation of complexity in development in general is mostly due to teams and budgets and time estimates not scaling accordingly.

A lot of that looks less like issues with full-stack development, and more with start-up culture where everyone thinks they're google.

Scrum is pretty gross, I agree.

Typescript I'm unsure about, I typically stick to vanilla javascript with a polyfill for the fetch API. I kind of doubt it adds another 20% of workload.

Tooling, linters, and bundlers I mean. That's just programming in general tbh. Cmake is probably my greatest headache with C++.

> Deployement, done by a devops engineer? you must be joking right? That's also the work of the full-stack dev..

I don't know about fancy Kubernetes setups and what not. If you've scaled to that level then yeah, you probably need someone dedicated to things like deployment.

But for the most part I just use shell scripts, git, and make files for deploying our websites. Works pretty well.

I don't agree with everything but I can resonate with you a lot. There are a ton of go to approaches and utilities, all the hipster shit, that people easily reach for and integrate it badly. Not talking about technical integration, but cultural / social integration. If one rubs X into your face he should at least reasonably be able to transfer the passion for it and care how it is applied. Commiting to a new X is an giant effort for small teams, if done right, but usually its just quickly added and then sticks there somehow. This is just one point of nonsense. Scrum and devops are good examples how things with good initial intent get corrupted. Hey I am already doing devops so why call it out if there won't be serious support from the company? Scrum is just pure cancer at this state. It literally didn't change since it inception. But back then scrum cut down infinite cycles to like quarterly. Now we are doing 2 week sprints with the same method and same overhead? Smart. Of course scrum is just for the tech people, so there are still 3 other layers of planning and a couple of meetings that you have to attend to.

Eventually there is no reflection on the things we do not great with.

The thing I find blows out estimates more is complexity in the codebase.

Typescript can be learned to a sufficient level that it has zero drag and saves you time when you need to refactor or understand someone else’s code.

Webpack is a pain to learn but like git you learn it once and benefit again and again.

But codebase complexity can knock estimates for 6. Someone’s crappy spaghetti design can below those assumptions in an estimate by an order of magnitude. And it could be a detail buried somewhere that wasn’t easy to discover. Like finding asbestos in your ceiling as you are about to remodel your house. Except a lot harder to explain to management!

One of the blind spots we have here is that I can't get people to think about the question "how long would it take to get a one-line code change into prod?"

That would mean looking at some things that people don't want to think about. So we try to feature toggle everything instead, and we dedicate extensive resources to keeping the old version of code as hot standby at all times.

These aren't bad solutions, it's just that they should be something we do in addition to being able to deploy quickly, not as opposed to.

I moved to desktop Windows development and couldn't be happier. People are more realistic, everything is more thought out and not a feather in the wind, and theres respect for time.

TDD is not when you have a dedicated testing engineer. The whole idea is to write tests before developing even the smallest of units (functions, methods): unless everyone had their own test engineer to pair program with, just imagine the friction if someone else was writing tests for you.

If you are talking about decent test coverage, and explicitely about decent system test coverage, then yes, a dedicated test engineer can help a lot.