Engineers are happy to pay for tools (hello, Claude Code). Libraries are quite different and it's a little uncomfortable to build a business on a closed-source, proprietary library.
2,052 karma · joined July 31, 2017
If you want to fix it:
- More free public spaces (parks with benches, squares)
- More free public events and activities (free concerts, art installations, plays)
- Greater physical proximity (it's hard to make eye contact if everyone drives)
- Wealth distribution (create a society where one's value is not based on their net worth)
- Encourage days off for community service
In other words, provide socially-funded incentives for people to be close to one another physically and remove income as a measure of value.
The current loop hole is that loans are not taxed so people take out loans against their assets thus never paying income tax. Tax those loans and refund taxes when the loans are repaid.
Here are some actual improvements:
- Record classes
public record Point(int x, int y) { }
- Record patterns
record Person(String name, int age) { }
if (obj instanceof Person(String name, int age)) { System.out.println(name + " is " + age); }
- No longer needing to import base Java types - Automatic casting
if (obj instanceof String s) { // use s directly }
Don't get me wrong, I still find some aspects of the language frustrating:
- all pointers are nullable with support from annotation to lessen the pain
- the use of builder class functions (instead of named parameters like in other languages)
- having to define a type for everything (probably the best part of TS is inlining type declarations!)
But these are minor gripes
You might have trouble finding small companies using anything but JS/Ruby/Python. These companies align more with velocity and cost of engineering, and not so much with performance. That's probably why the volume of interpreted languages is greater than that of "enterprisey" or "performance" languages.
With LLMs, the volume of code has only gotten larger but those same LLMs can help review the code being written. The current code review agents are surprisingly good at catching errors. Better than most reviewers.
We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way.
One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
Second, always pad your estimates. If you have been in the industry longer than 6 months, you'll already know how "off" your estimates can be. Take the actual delivery date, divide that by the estimated date, and that's your multiplier.
A senior role in NYC for 155K (plus bonus, which they do offer) is nothing when you factor in the cost of living.
Are you a designer or an engineer? The perspective below is for engineering:
- Designers are going to be your biggest challenge. There is a wide range of design skill level in leveraging the Figma versions of your design system and you need to have a strong partner in design doing the same thing you are on the dev side.
- Start with primitives. Get everyone using the same colors, fonts, sizes using shared functions. Then introduce theming. This should be universally adopted. Document.
- Rather than roll out a new design system, canonize the most commonly used components into a design system. This way, you get automatic adoption. Speaking of adoption, that's going to be your measure of success.
- Use tools to understand who is using your design system and who is not (there are tools but strong CODEOWNERs files are key here)
- Create documentation and training on the use of the design system. Don't stop teaching others on the use of the design system, especially if they are new to the company.
- Create a contribution model: how and when does a component become part of the design system?
- Take ownership over global components like the nav, headers, and the footer
- I've tried going higher order with form and page builders being part of the design system, but that's a lot harder than it seems
My learning is that a design system is important, but it doesn't get a lot of love in many organizations.