Apologies for my meta-meta-comment :) I've been writing code for ~30 years in various languages, and today my brain can't compute how people find any syntax other than this more intuitive:
data Thing
= ThingA Int
| ThingB String Bool
| ThingC
To me, the above syntax takes away all the noise and just states what needs to be stated.
I know next to nothing about these but a friend of mine was grumbling the other day about why can't he just use his electric car's huge battery to power his house. It sounded like a great thing? During the day his solar panels charge his car and at night it could power the house (to some extent). I remember him saying something like this is being trialled in Japan maybe? Anyone knows more about this?
That functionality is called "vehicle-to-grid" or V2G sometimes. The F-150 lightning has that capability built in, and there are several companies working to bring devices to market which will act as an interface between the vehicle and your home's electrical panel.
It’s coming soon. Our car’s battery capacity is comparable to the house batteries, so during extended rainy power outages, I’d love to be able to fast charge the car, drive it home, and top off the house battery. (Adding 50% per trip.)
The only other alternative is installing and maintaining a propane generator, but that’s more time then a few round trips into town per year (especially since the grocery store has a fast charger, and we invariably need to purchase food during these events).
Also, they ended up rationing propane this year, since the delivery progress with the big trucks was hampered by road conditions, and demand was unprecedented.
> I think for the last 10 years of my career at BigTech, I can't possibly quantify my impact in numeric terms because they were such small pieces of gargantuan projects.
Honestly, this would make me depressed rather quickly. I can't imagine not knowing/experiencing my impact via the work I do. Maybe it is one of the personality differences between people choosing to work for startups/scaleups vs. big tech (no judgement either direction, just my conjecture).
It’s a trade-off. I don’t get to implement the cool ideas I feel might greatly help my current employer, but their expectations of me are generally low and I get paid enough that I can retire a little over 40. Works for me, its not like I’d actually get paid more if I did something cool anyways. That energy is better spent on my own projects.
I’ve generally noticed attaboys and prestige aren’t really personally fulfilling anyways, no one cares and my work will probably be irrelevant in a year or two regardless. A bit nihilists, but it helps one detach after a long day and deal with the occasional failure.
I know a lot of people dislike bitcoin here but I'm wondering (with the huge assumption that its value stabilises over time) would it not actually be a better solution? Not just from an obvious logistical but also from an environmental perspective? I'd imagine gold mining to be much more destructive (both to nature and to human life).
I wonder if they can use it? As a noob I see that crypto value is very volatile and don't have intrinsic value, unlike gold that somehow is accepted universally as valuable.
Not sure if you’d win that bet or not but my anecdata is that me and probably the majority of my social circle spend near-0 on alcohol and sweets. They/we buy good quality food and that became mighty expensive.
Pretty much yep. I'd also say it boils down to age which tends to correlate with having a family and also better WFH conditions. When I was young, single, living in a small apartment going into a nice office was great. Nowadays I'm older, have a wife, a kid, a house with a nice garden office. I still love and enthusiastic about what i do but thanks to the internet i can do it from the comfort of my own place.
At our company we came to the same conclusion. We have a DSL that is essentially a programmable schema to describe the shape of the data (more specifically a contract) you want to capture as well as how answers and decisions are derived from it. The only hard validation we have are types, eg. you can't put letters in a box that captures a number type. Other than types the rest is soft-validation which means that you can input anything, even if it is partial or not quite correct, and the system will do its best with what it has. In tandem, at any point in time you can ask the system to tell you what is missing and/or incorrect. All this then affects the lifecycle of the information, ie. you can't move past certain checkpoints in the workflow if the information is not in the required shape. In the context of a medical software imagine you can fill in just the things that will get you back meaningful answers to help you treat someone and you can deal with the rest after to make the case complete.
It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors. How to make the "right" choice of unusual is where the interesting questions lie but that is highly context-dependent and can't easily be generalised into a blog post.
Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.
Yes, but whether it will continue to do so, once again, has little if nothing to do with the tech stack.
I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions. And, when you’re looking at longer shelf life for your code, then the article becomes justified in making your codebases as boring as possible because thn you’d like to employ only the patterns that have truly stood the test of time, instead of polluting your code with novel approaches.
> I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions.
I think all the people who are adopting Rust, who wouldn't have touched C++, would disagree with you.
Design Patterns are from at least 1994, when GoF wrote them down. Ideas like DDD are some 20 years old. As is e.g. Event Sourcing.
Actually, by your reasoning, Event Sourcing would be the preferred architecture for everything since the oldest written human sources were event sourced (bookkeeping grain).
As always, what is best fitting "depends". Battle tested is one, but never the only one, parameter to decide with.
> Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.
Exactly. That's the reason Facebook gave for adopting Reason (OCaml).
Not in 2022. Half a century ago, yeah, it was a highly creative field, but these days almost everything has been done. (Even ML is decades old, the hardware caught up.) And this is a good thing!
We have been doing this long enough that it should be "boring" now, in the same way that constructing buildings or bridges is "boring", eh?
> In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors.
Sure, but that's a decision that should be made cautiously, with good reasons to think it will work. In other words, innovation should be "boring" too, at this stage in the game.
Reminds me of Sendgrid. At the beginning, they were faced with using an off-the-shelf MTA (mail transfer agent) or writing their own. As a core competency, writing their own turned out to be a major competitive advantage.
This is a very good point. There are definitely "risky novel" choices that could make your company a success. But I've also seen many teams drowning in a soup of random tech choices.
I'd love to be able to write some more specific advice on this topic but mostly I just want people to be mindful of the impacts of their choices and actively choose risk rather than having it sneak up on them.
My first time as a team lead I saw value in little side experiments on non-core parts. Now I think that's only OK if there is time and budget to roll them back if they prove to be a bad fit. Otherwise they accrete and become a drag on velocity.
reply