HN user
Sam Altman went from "I'm doing this because I love it" to proposing to receive 7% equity in the for-profit entity in a matter of months. Now he calls out researchers leaving for greener pastures as mercenaries while the echo of "OpenAI is nothing without its people" hasn't faded.
Catholic churches are quite conservative in their own ways, primarily set up by Christian missionaries with the mandate to convert.
The english language helped, sure, but it's the lack of opportunities in their own state and the higher education levels that created the conditions for the immigration to Middle East. Kerala also had a long history of trade with Arabs.
Yes, there is restriction on beef consumption in India but nobody protests for pork while in the middle east - it's all about which side the bread is buttered.
This is like saying more than a quarter of the code is from oss, examples and stackoverflow before LLMs.
Also that it maintains insertion order (since Ruby 1.9) opens up more use cases.
Elon Musk's Trump like behaviour - for e.g. poll regarding Twitter HQ, edit button, openly discussing product ideas etc would have definitely spooked Twitter. This would have led to serious talk and conditions that he should restrain what he puts out as a board member - which probably wasn't worth the trade-off for Musk.
The Matrix
Can you be a "VP of Sales" without ever doing any sales? Can you be a head chef without ever cooking?
Sure, you can be immensely impactful being a people leader and a conduit between business and tech without ever having written any code. But you can't call yourself CTO if you haven't written any software yourself without diluting the meaning of the title to homeopathic levels.
Would totally recommend this book "Patterns of Enterprise Application Architecture" by Martin Fowler
Two books that might help:
Courage to be Disliked - it's helped me put different life problems in perspective.
Mountains Beyond Mountains: The Quest of Dr. Paul Farmer, a Man Who Would Cure the World - This has been on my bookshelf for a long time, I just picked it up recently, looking for meaning after witnessing covid devastation around. Just a couple chapters in, but it is a really inspiring book.
Product companies ideally optimise for outcome (growth/delight/adoption metrics).
Consulting companies tend to optimise for output (delivering on time, code quality, reported bug counts, number of stories, sprint velocity etc.)
A full time product engineer has more skin in the game and freedom to work across the stack while consultants might be restricted to non-prod environments and therefore limited access to infra/devops work and prod support/troubleshooting. YMMV.
There is a huge learning in supporting what you build and not getting that experience can be a limitation in consulting.
However consulting offers you the opportunity to work across domains, tech stacks, work with new people, travel etc every 1-2 years whereas in product companies a commitment of 2-3+ years is desirable.
Finally, it boils down to quality of the group of people you are going to work with. A consulting firm with higher density of talent would be more interesting than a mediocre product team.
Java language gets its hate from its historical lack of focus on developer happiness. Beyond the language, the crufty experience with Java Bean, Java EE, WebSphere era all contributed to this.
Thankfully, Java ecosystem has learnt from other languages and frameworks and with Java 8 onwards has addressed some of major pain points For e.g. lambda, streams, vars, text blocks, records etc,
On the other hand, Shopify and Dropbox that used Ruby and Python heavily had to invest in type checking to bring back some sanity and this is evidence that beyond a size of code base, static type checking is worth it.
Considering these, I find Java to be a very good option to build stable enterprise applications compared to Ruby or Python.
There is intentional or incidental technical debt which is debt taken for good reason because of lack of enough context, YAGNI, or whatever with the understanding that it will need to be revisited and the developers are aware of it. This one is easier to deal with and is usually contained well because it is a known-known.
Then there is accidental technical debt that is mostly due to lack of design skill / judgement that results in code smells, spaghetti code, poor abstractions and a codebase that sucks the life out of everyone.
When most people write about technical debt, they refer to the former while it is the latter that is much more costly and prevalent and yet, avoidable.
I have used craftwork design method framework to build startup landing pages and websites.
https://craftwork.design/downloads/method-4/
It ships with many layouts, blocks and components in React that you can mix and match for building landing pages. If building a page from scratch isn't in your wheelhouse it's quite useful to get something out quickly.
React Native/Expo
Mobile app development used to take a lot of effort with separate builds for iOS/Android and low code reuse. React Native changed the game and made building mobile apps easy and much less expensive.
Gitlab is a great service and a great alternative to github and bitbucket. But it has been quite flaky over many years and it's quite surprising they haven't prioritised system stability over everything else. https://twitter.com/gitlabstatus
Gitlab has been a fully remote proponent going back a few years and these persistent reliability issues add some doubt to that model - even if there might be altogether other issues in play.
I have found agile rituals like standups, retros, iteration planning meetings etc helpful because it gives multiple forums especially for junior developers to participate. These help break down information asymmetries that can creep up.
However, it is essential to keep in mind why these things are done and not just cargo cult them.
I have felt Scrum is cargo cult agile which helps non technical managers retain power post "agile transformation" in the form of "scrum master". Just that title changes the power balance in meetings and kills the spirit of what they are meant for.
Lack of motivation and thus focus could be due to many factors. Finding the root cause is the first step.
If it is due lack of social contact (due to working from home), try hanging out with friends or acquaintances everyday. It's a good idea to do that anyways.
Lack of exercise and exposure to sunlight can be a factor. Being outside on a nice sunny morning really cheers me up. Carve out time to walk in a park or in the midst of nature.
If the work isn't interesting, try to see if there are other places you can contribute and ask for it. If you can also identify a interesting problem worth solving then you can own it and run with it.
Lack of appreciation at work or from colleagues can also be a factor. If that is the case, acknowledge that many are also going through a rough time at this point. Perhaps you can help set an example and try influencing the culture a little bit. For e.g. an attaboy on a solid PR to a colleague or engaging in conversations outside of work before start of meetings.
These are not unusual traits when starting a company as a technical founder.
Its actually not unusual to have technical cofounders who have no prior software engineering work experience.
I have an enterprise B2B app on react native with expo and the experience is great. Code push (over the air updates) on expo is a killer feature and something which Flutter doesn't seem to have yet. If you are a small team that uses/knows React then React Native can be a better choice if there isn't a compelling reason not to use it.
The usecase in the article was to parse logs from a CDN serving cached content not an app server which serves every request.
Use Quip for documenting features, ideas, check-listing, task tracking https://quip.com/
Having one place for chats, documents, tasks is great. Its fast, simple and real-time!
I think the role of AI in eliminating these jobs is overstated compared to the role of Cloud, Dev Ops automation and faster iteration cycles afforded by relatively better abstractions and tools for building software compared to 10-15 years ago.
A lot of these large IT companies relied on long term maintenance contracts for infrastructure and legacy software with unnecessarily large teams on self serving time and material (T&M) models. But these days, even large enterprises have to innovate to stay in the game and their experience with top end Agile consulting firms made them realize that you can do with much fewer people with automation and hiring better. On the other hand, the large IT companies got stuck with their old model and without training and experience on challenging projects, the talent atrophied even while having to eek higher salaries every year due to inflation and talent loss to startups and others.
However, the numbers being reported so far aren't huge compared to the employee sizes of these companies. For e.g. 5% layoff would actually be a reasonable trim on an annual basis. In that sense, the carnage hasn't started yet.