Hacker News Reader

>instead of a smaller number, with consistent skills, shepherding the project from start to finish. This is opposed to designs for deliverable-focused Quality and market fit.

Ultimately, if companies truly valued this, they would've done more to keep talent. Instead the majority keeps looking for the fine line between "they will quit" and "they will stay", even going so far as disregarding the basic premise of "a happy, stress-free employee produces more valuable output".

>I’m not sure that things are sustainable.

Of course things aren't sustainable. Nothing points towards most companies aiming for sustainability in the first place.

> a happy, stress-free employee produces more valuable output

The output is certainly more costly, but does it bring in more income for the company?

Are there any studies published about this? I imagine Big Tech would keep it as a closely-guarded secret.

> The output is certainly more costly, but does it bring in more income for the company?

Depends. A Mercedes is a lot more expensive than a Honda, but Honda's a bigger company.

Both are quite successful, though. It depends on the metrics and targets.

If I did the math right (euro vs yen, and wikipedia has different years) Mercedes is slightly bigger than Honda. Honda sells more cars in the US, but Mercedes sells much bigger trucks (freight liner is Mercedes), and both sell around the world.

Considering Google came back on its brain teaser interview practice and several other practices, I have a hard time believing their decisions are largely empirical as opposed to short-term rational. This is even worse for "happiness" since individual happiness extends all the way to communities and back into society. Not only that, happiness is very dependent on culture, upbringing, cost of living and more.

However, even HR at small tech companies in Europe follow the basic idea of "if employees are happier, they will produce more output!". Assuming this isn't a pretty lie, we know people are generally happier not having to live paycheck to paycheck by force. We know people are generally happier not having to sit in traffic jams because of a 9-5, at the office mentality. Even modern hiring practices are based on distrust and making things more tedious for both sides of the equation, when there are solutions which would at least help the employer out. There's plenty of room for them to actually follow their own advice, and we have plenty of studies at least suggesting benefits of remote work, less hours, different work hours, etc.

The short tenures also lead to a bias toward technologies and techniques that look good in their first 0.5--1.5 years of usage but then ages badly with increased maintenance.

NPM packages are by far the worst offender of this.

Some packages are great, but others drop maintnentece completely after a year of support. Then you have to move off of them because they are tied to old versions of react or other core packages.

> Some packages are great, but others drop maintenance completely after a year of support.

Indeed. I would consider it one of the key skills for a JavaScript developer to be able to differentiate between packages that will be maintained and those that won't. Luckily JavaScript itself is quite straightforward, so JS devs should have plenty of time for learning this stuff.

Oh, so all you need is somebody who can see into the future? Sorry mate, these guys are already busy otherwise as stock brokers.

I've tried to come to terms with TypeScript during the last two months, but I am sorry, it is still too messy and does not give me enough guarantees about my code.

What I would love is a Swift to TypeScript / JavaScript compiler.

Not quite what you asked for, but here's a relatively mature Java to JavaScript compiler: http://www.gwtproject.org/

I wish GMail stil used GWT. The current UI is a dumpster fire of sluggishness, even with a brand-new CPU and plenty of RAM.

It made me switch to Thunderbird. I had to sift through tons of mails to unsubscribe, without the Promotions/Social/Updates tabs.

The ones that kept sending me mail go to spam now.

Sorry, I wrote my last commercial Java App about 20 years ago. I don't intend to start again :-)

> Oh, so all you need is somebody who can see into the future

Well yes, anticipating future developments is one of the main things a software developer does. And IMO one of the main differentiators between junior and senior developers. A library that has a history of regular maintenance is unlikely to get suddenly dropped. And a library that has a large user base will have its maintenance picked up by others if the original maintainer(s) do step down. If the library doesn't meet these criteria then you probably shouldn't be using it.}

I don't think you can realistically use Swift client-side. But Rust is an increasingly viable option (for browsers that support WASM). WASM compilation is built in to the official toolchain, and the js/ts-interop story is quite good too at this point (modulo some overhead when calling between JS and wasm).

> I don't think you can realistically use Swift client-side.

I beg to differ. I've been using it client-side for years. I do not like the hybrid offerings.

Do you mean client-side as in an ios/mac app? If so then yes my bad, I meant client-side web (which I believe the OP is trying to do as other they presumably wouldn't be using JS/TS seeing as they don't seem to like it). Of course, client-side mobile apps are great in Swift. I just would't recommend compile-to-js. If you do have a good compile-to-js workflow for Swift I'd be interested in hearing about it.

Yeah, I write the whole app, and server interaction is usually done through a “faceless” API.

Rust seems like an excellent server language, and I look forward to seeing it get more mindshare. Swift smells a lot like Rust.

But I’ve used PHP for my backend work. I’m not really a backend engineer, and I am sure it could be done better; even with PHP.

One of the reasons for my choosing PHP, is because it is so widely known, and is a perfectly good language, as long as it is written well.

There was that study that was done recently, where they showed what I call “the fishtank graph.”

This was the graph that showed which server languages were in use.

PHP was this fairly steady line along the top, and every other language looked like gravel in a fishtank, along the bottom.

Sounds like the criteria you outline for using a library can be learnt in a second. Why is it then a differentiator between junior and senior?

I have been thinking about Rust, but it has too much stuff like ownership I rather don't want to think about on top of the already complicated things my code does.

A compiler from Swift (or a subset of Swift) to TypeScript would make it a viable option for me. Maybe I write it myself.

It's a differentiator between junior and senior because senior people need to make "the call" on using a technology, juniors don't.

There's a couple of other heuristics for whether or not something is worth using on a project (like complexity of learning, and context within a larger stack), but suffice to say it's about looking past a specific problem and on to subsequent problems down the line.

Juniors often make the call too. Seniors make the call on major things, but there are a lot of little things juniors get to decide, and some of them become bigger over time.

> A library that has a history of regular maintenance is unlikely to get suddenly dropped. And a library that has a large user base will have its maintenance picked up by others if the original maintainer(s) do step down. If the library doesn't meet these criteria then you probably shouldn't be using it.}

Projects die all the time or start being very lazy with the maintenance. Not that I expect anything more, there is literally no money in them.

The criteria I like to use is "Will I be able to fork it and fix it when it goes unmaintained"?

Scala.js is remarkably effective, and you can use Scala in a fairly Swift-like way.

Yes, I have used Scala.js before for a project, about 6 years ago. Scala wouldn't be a bad choice, but for some reason, I prefer Swift.

I think I've just come to a point where I don't want to split my attention between formalisms for reasons that have nothing to do with the formalism, and just its ecosystem.

I've spent the last couple years using Dart as a backend language, and even working with the Dart team on a couple improvements to core packages. It's a really nice language, supported by Google, and transpiles to JS.

Same as for Scala. I've shipped a Dart app last year, but the language is not as nice as Swift, and reminds me too much of Java.

Did it remind you of the bad parts of Java, or was it a more superficial resemblance? When I've used Java, what bothered me was the apparent overabstractions and complicated frameworks for simple things. I've never seen that in Dart.

I feel like Dart gets me reasonably close to the kind of elegant, intuitive code I can write in Python...but with static typing.

Dart is a fine language. But I struggle to understand why it exists in the first place, there is nothing in there that is done better in Dart than in other languages. Yes, Java has some "Enterprise" problems, but the language itself is just like Dart. Really, they could have just used Java, they probably didn't do it for legal / political reasons.

What I like about Swift is its "protocol oriented programming", which is basically pragmatic Haskell type classes. There is just so much done right in Swift, that I have a hard time going back to any language that doesn't have it:

* protocols, integrated with struct/enum/class

* dot-syntax when the context is known (like .blue instead of Color.blue)

* immutable data structures via copy-on-write, nicely integrated into the language

* best integration of optional type (like Int?) I've ever seen in a language

* (optional) named function parameters (in the beginning I was annoyed, but now I am a big fan)

* the way exceptions work

* cheap garbage collection (kinda; ARC is working like garbage collection for most of the code I write)

* great package system

* great IDE (Xcode)

Ah, thanks for clarifying. I don't think Dart is quite so similar to Java that it needn't exist, but I understand what you meant better now. I haven't used Swift, and I'm not likely to, but it sounds pretty good.

How is the experience in debugging production issues with this sort of transpiling? Like how do you match a Javascript stack trace of an error back to the Dart code?

I actually wasn't transpiling to JS, I was running the Dart VM. VS Code + standard Dart extensions works great for debugging.

>* one of the key skills for a JavaScript developer … to differentiate between packages that will be maintained…*

Also, a core policy of any development company, using any languages/frameworks/etc but more so if using JS currently due to the exceptionally high churn, is monitoring dependencies for liveliness so a transition to something else when they inevitably fade can be planned in advance and not implemented in a mad rush (leading to bad decisions) when deprecation notices start to arrive or, worse, after deprecation when security issues become apparent but not fixed upstream.

It needs to be policy, with someone who is responsible (or hands out responsibility but is where the buck stops), or it won't get done reliably. It isn't an interesting task, at least not for most people.

It's likely most of those packages were created on the job and the person left the company (and package maintenance) after 1-2 years

Presumably those packages are open-source, so you can just fork, update, and continue using them?

I get why the old timers say they prefer proven technology now. When i had less then 4 years of experience every new framework was worth checking out no maater how unproven it even was.

My first job out of college was maintaining and refactoring a 10+ year old Perl CGI application. After a bit of adjusting, I found it quite rewarding to refactor overgrown messes into nice and readable OOP patterns, and more significantly, it was character-forming because it really hammered home the point that one person's quick fix will always become someone else's maintenance burden down the road. It's definitely been a positive influence for me to experience the other side of the stick early on in my career.

One of my first jobs was as a maintenance programmer for about 100KLoC of 1970s-era FORTRAN IV.

Not one comment to be found, short, inscrutable variable names, no indenting, and having been stepped on by dozens of junior devs before me.

It was "Voodoo bug fixing." I had to close my eyes, and throw a dart, hoping I got it.

It taught me, very early on, to write good code.

That sounds like the stuff of legends or a horror novel.

Imagine me, with a flashlight under my chin, as I recount the story...

It was an email system; before what's-his-name-The-Nanny's-husband "invented" it.

Same. I'm in my early forties now. Most new technologies are just recycled ideas from older tech.

This has been hitting me hard lately in my late 20s. I'm realizing all of the cool "new" concepts I'm learning have been around since the 60s

It's made me rethink the supposed "skill reset" that happens in software which leads to software developers leaving for other roles more often than other engineering disciplines.

I really like working on a project for 5-8 years at a time and really building tools to make the system run smoother and reliably. It really has backfired, I'm out of touch in the latest interviewing fads and I think hiring managers wonder what's wrong with me rather than thinking I'll be a good hire.

I've been doing 4-5 and it's the same for me.

I just stopped looking for work. I got tired of being insulted, right off the bat.

Too bad. I could have been an awesome hire, for a number of these companies; especially the smaller ones. I'm not "behind the times," at all, and would have been happy with far less compensation than most.

It was funny, these little shops were doing the same kinds of interviews as major-league FAANGs, even though their workflows and requirements (and pay) were drastically different. I guess it's a case of "Monkey see; monkey do."

A lot of companies have found success in treating engineers fungibly. If you think of the engineers as part of the computer system, this actually adds resilience in that front, traded off by resiliency of the software itself.

If you lose 10 software engineers due to the bus factor, the fact that you already are treating engineers fungibly gives you resilience on that front.

Making people fungible dehumanizes them. Personally I hate having to job hop just to get what I wanted from this industry.

The business community wants everybody and everything as replaceable and fungible as possible, to its long-term detriment. That so many see short-term "success" and call it that should be far more appalling than it seems to be.

Take Circuit City, for example, which, when it was already struggling, let go all of its senior sales people on the floor and replaced them with minimum wage. The knowledgeable salespeople was pretty much the only thing going for Circuit City at the time. Customers noticed, responded, and the business fell off a cliff

> Making people fungible dehumanizes them.

that’s just capitalism

No, it's not. Far more capitalism in many other countries operates with workforces that have been there for generations. We used to offer pensions here in the US, that is still going elsewhere and in government

Human capital has value and appreciates over the long-term

> Personally I hate having to job hop just to get what I wanted from this industry.

A couple of times I've landed at a good company, where I figured I could stay for a long time and build something resembling a traditional career. But something invariably changes - the company gets acquired by some MegaCorp, a leadership changeover, your awesome team gets disbanded and scattered, etc... c'est la vie.

I'm going through this right now.

Really great team, great project, great codebase, loved a lot of things about it.

Then a leadership change happened. I've got a new job, gave my notice, and hopefully will keep in touch with the people I like here. Very bittersweet time.

The story of my career. Literally EVERY good employer I've had suffered some change a year or two into my tenure that turned the place around... into a shithole.

In my experience, the industry is focusing on developer happiness at the expense of developer satisfaction.

Can you elaborate on the difference? When would I be a happy developer but not a satisfied one?

If your compensation, benefits, and perks are great, you might be happy, but if you're a functional programming expert spending all your time writing up TPS reports on a spaghetti legacy COBOL application, you may not be satisfied.

Depends, how much am I getting paid?

Sorry, I'm old and jaded.

> Wages have been rising for software people since long before COVID

Inflation is "solving" this problem. No way are companies going to give across-the-board 8-10% (or more) cost of living adjustments this year. And it's a safe bet inflation will still be high next year.

as a general rule my ADHD tends to get my burned out on being at the same place, same tasks after 2-3 years, and then I decrease in productivity. So if the system was set up to retain me longer than that, I don't think I would take advantage of it anyway.

I once worked at a company that specialized in R&D. Short projects, ad-hoc teams, etc. Kept things fast, interesting and ever changing. I consider that time to be one of the best (and happiest) of my career.

But then some of our projects turned into production systems, and the place started to take on a more "traditional" software shop feel with terms like SDLC and CMMI being thrown around. Then we got bought by a bigger company - that was the last straw for me. Oh well, was nice while it lasted :(