There's a reason there are IC and manager tracks at most companies employing devs. You can keep refining your craft as an IC and become a Staff/Principal/Distinguished. No need to become a manager to get promotions, more money and/or more responsibility.
A big chunk of the knowledge contained in enterprises is in spreadsheets. It's a no brainer to make that more easily accessible to LLMs. Wrap a thoughfully designed agentic framework around this and you presumably get a cheap junior data analyst that you can ask arbitrary questions of to better optimize value delivered through the knowledge you have. Anything from "free" drill down reports by territory on sales or ops to potentially running monte carlo simulations based on identified correlations to get a sense of the best classes of improvements to invest in to reduce shipping costs, improve sales conversions in specific verticals, etc.
I don't know if this is the framework, but this is one of the problems that needs to be effectively solved for large spreadsheets to unlock access to the data more efficiently.
This is the hot new word in the LLM space. Was this picked because LLMs are losing luster for broad, cross-domain applicability? What systems actually demonstrate this behavior?
I'm not short on LLMs, but I can see a future where Gen AI in the creative space (image, audio, video) outpaces LLMs in terms of impact.
In this context it could be able to do multiple actions in order to address an ask from the user: read cells, documentation, edit cells, and perhaps even read the result from the edited cell before answering. i.e. "Can you create a new sheet that focuses on the Countries where the sales happened, including YoY differences, and tell me which countries are outliers and for which reason(s)?" (probably very far fetched given the level of progress Excel has achieved in 20 years).
Loads. Back in 1999 I built an entire suite of DSLs for generating web applications - you described objects, properties, validation rules, newsletter settings, commerce functionality, forum rules, etc and it used some combination of compile time code generation and run time parsing to deliver the functionality, substantially decreasing the dev overhead in building "good enough" web apps.
I will also note, that while it's possible to build a parser generator for external DSLs, for many use cases concrete syntaxes with existing parsers work fine. Back in 2000 I created a set of DSLs for generating web applications and I used the concrete, serializable syntax of XML as I got the capacity to describe types fairly clearly and I didn't need to generate a parser (or more importantly, an IDE plugin with auto complete and type validation). I figured I could always write a lightweight interface to display the info from the concrete DSLs to save business users from the angle brakcets. Json would allow you to do the same these days.
It seems like people make this really complicated.
There will occasionally be network partitions. When there are, a given node can either respond (potentially inconsistently) or not. So you pick some balance between consistency and availability. Latency is really just a proxy for availability - as latency tends towards infinite, availability tends towards zero. Of course you can wait until the network partition is resolved and the nodes are caught up - but I think it's simpler to consider that as not being available for a period of time rather than as having a high latency at that time.
Consistency or Availability - you don't have to pick one, but the more consistent you want to be (in the case of network partitions) the less available you'll be.
Disagree on latency, for certain classes of applications it really matters. Latency can be caused by a myriad of things, but if that thing is your means for cut over, you haven't failed to respond, you've failed to respond in a timely way. The telco space has strict latency requirements. If you have a failure which results in erratic behaviour on the network due to the database taking time to handle a node failure you aren't in a good place, it has a financial impact.
There are databases that can provide high consistency and availability.
If your decision between Consistency and Availability has business implications, you definitely aren't making this "really complicated" but rather a business logic to adhere to.
Failing to understand the implications of one over the other is often sign of immature architecture.
Lean software development has a lot to say about this too - check out anything on value stream mapping and if you haven't already, try "Principles of Product Development Flow". It's dry but good.
Pedagogy, like any other field is constantly developing. We are continually learning new and better ways to teach materials and thus I think the continued evolution of teaching materials has the potential to be a good thing (and I've created curriculum for professional learning, for grad school and for bootcamps).
It is true that just because a book in newer it is not necessarily pedagogically better
It is also true that a poor selection of content or understanding by the author could doom a book even with better pedagogy.
All that said, I love the idea of OSS books/exercises for teaching - I don't know if a sufficiently engaged and competent (domain + pedagogy) would evolve around and/all of them, but it'd be a fine experiment to try!
It would also be great training material for LLMs to help them to tutor using more thoughtful metaphors and examples.
I think that researching pedagogy is very difficult, and, like many scientific fields, it is hard to reproduce results found in papers. (I am not an expert in this area -- I am just a former teacher with around 10 years teaching experience.) One of the main things I notice is that standardized test scores are not really improving. I think that high school students today would score about the same as high school students in the 1980's if they were given the same multiple choice tests. This implies to me that the field has not advanced a lot. I do think that LLMs and other computer based teaching could help.
It is, and that misses the point. Lets assume hand washing is an hour and contact time for washer dryer is 10 minutes. We have absolutely saved 50 minutes of labor. Unfortunately we all tend to fill that time up with extra things. Maybe we got a bigger house and have a lawn to mow. Maybe we're a two income household where the person doing the washing is also working, maybe we're checking email.
The point is that the majority of people make the choice not to leverage the time saved in additional pursuits but to cram more things into their week.
I certainly personally feel a little more frazzled than I believe I did at a time when the Internet was only accessible at big corporations and universities and when phones were (for most people) connected to wires in their houses and the only thing a watch could do was tell time and set alarms.
This is not (at least for me) a criticism of technology or innovation. I happen to be unreasonably obsessed with both. It does raise the traditional question of "what is a good life" and how can we be thoughtful about how we engage with technology to ensure that we replace drudgery with joy - not just more tasks, things and obligations.
Before washing machines they didn't really have any choice but to wash their own clothes (except for a few very rich that had servants to do it).
The same is true of many things - a huge proportion of the population used to be involved in subsistence activities just to grow food, and raise animals for food.
Of course we still have to eat but a far smaller proportion of the population is now required to do those things enabling society to persue other things (science, technology, arts, ...)
Yup - I was intentional with my language for a reason. But when I see most everyone I know making those similar choices I have to wonder what's an appropriate way to frame and engage with technology in a way that makes our lives better match our goals and whether we're all going to have to get much better at that to avoid becoming "drowned in plenty" :)
