- bitexploder parentI met my wife on IRC in the late 90s, but meeting on a MUD is a level above that and I bow to grandparent.
- My first MUD I ran was there on mudservices! I learned C and become a programmer because of MUDs. MUDs and my obsession with building them in high school took me on a very long and statistically improbable journey of success in my career and life.
- Anecdote, but some of the time when I am blasted after a day of thinking for my job all day a design session randomly throwing shit at an LLM hits the spot. I usually make some meaningful progress on a pet project. I rarely let the LLM do much pure vibe coding. I iterate with several LLMs until it looks and feels right and then hack on it myself or let the LLM do drudgery like refactoring or boilerplate to get me over the humps. In that sense I do strongly agree.
- This. Even resin printers only get you kind of in the neighborhood of tolerance. Lego primarily uses injection molding for their parts. Their molds are insanely tight and low tolerance. One of the key costs of Lego bricks is the lifecycle of the molds. They don't last forever and lose tolerance over the course of several hundred thousand injections. Managing these molds and the sheer variety of parts they produce borders on logistical insanity. It is one of the most impressive logistics operations on the planet. I can build a functional car with fewer discrete pieces than large modern lego sets.
- AI can do the most basic first pass of creation. For a senior engineer writing code is a relatively small part of the job. There is a paradox where complete novices can churn out content / code that looks decent, but is superficially empty or a maintenance nightmare waiting to happen if the complexity increases even a little. On the other hand, for senior engineers, it is truly useful. If you treat the AI like a modestly skilled junior developer and actually still design your software it just does a lot of the boring boiler plate for you. You are still doing almost everything important. When you understand the code and could write it yourself you can almost always keep the LLM on track towards your objective, achieve appropriate code quality, and finish the task quicker. They are also really decent at refactoring and doing boilerplate. Especially in languages like C++ with a lot of boilerplate.
I imagine the same idea above holds for media (music, film) as well. When you understand how to prompt and can get the right scene with all the right constraints you are saving time. The human is still composing, editing, and storytelling. The LLM again becomes a relatively interesting but boring tool in your workflow to speed up some aspects.
Right now the power of LLMs is that you can funnel parts of your workflow that they can handle well and you save a lot of time for minimal design cost in terms of how to use them.
- Oh, I have no doubt they are at Google. I was just trying to say that the author was not really making a commentary on UX directly. The author was trying to make the point that understanding what sort of products and problems users have is a valid long term strategy for solving meaningful problems and attaching yourself to projects, within Google, that are more likely to yield good results. And if you, yourself, are doing this within Google it benefits you directly. A lot of arguments win and die on data, so if you can make a data driven argument about how users are using a system, or what the ground reality of usage in a particular system is and can pair that with anecdotal user feedback it can take you a long way to steering your own, and your orgs work, towards things that align well with internal goals and or help reset and re-prioritize internal goals.
- Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.
- There is a lot of nuance to their point. They are saying, in the long run, career wise, focusing on the actual user matters and makes your projects better.
Google UX is decent and the author was not trying to comment on UX as a thing at Google. More that, if you follow the user what you are doing can be grounded and it makes your project way more likely to succeed. I would even argue that in many cases it bucks the trend. The author even pointed out, in essence there is a graveyard of internal projects that failed to last because they seemed cool but did nothing for the user.
- There is an interesting thing. If you study the socialization patterns there are only small to moderate average differences and huge overlap between individuals (all genders). This is in part social construct and in part nature. When you average things statistically you can mislead yourself pretty quickly reading some of these studies.
There is more overlap than not. So, how do we reconcile that with how things end up: network effect. Small biases in socialization norms lead to significant non-linear outcomes due to amplification of these biases leading to norms that exaggerate these biases and end up creating norms that are quite distorted from the average. Leads to some significant consequences for how different genders end up socialization.
- I don't think it is complex. The theme of a social group is just there as a filter. If you like rock climbing and meet someone at a rock climbing gym that person is far more likely to be interested in things you are interested in: physical fitness, the particular mental challenges of rock climbing, etc. It was just an example. I won't analyze the sexism or male only nature of the fraternity, but I think Freemasonry anecdotally reinforces the idea that men want/need/form these kind of clubs more than women on average.
When we study this we notice very small actual bias at an individual level on socialization preference. The differences are modest and more like slight preferences. There is more overlap than not at a local individual level. What gets missed is that even though the differences are relatively small, the network effect greatly amplifies these small variances resulting in non-linear outcomes. Even small biases at an individual level essentially produce significant effect in socialization behavior.
- Is there any evidence this is at all bad in the weight room? It isn’t repeated at enough volume and if you have a diverse enough full body routine making everything stronger including connective tissue it would not matter. Changes in load are a better predictor for injuries in studies I have read.
- Basically the whole point of the Freemasonry fraternity as well. Male only. It is dressed up with some altruistic goals and rituals, but it is a social club for men essentially.
- Hmm, I sort of learned ad-hoc. Joe Celko's books were good back in the day. I never read something a lot later that was an "aha" for me. I think I was a little resistant to "NoSQL" databases for a while but eventually they made sense to me. I can't think of a single resource or turning point. There are probably some very good books out there now. The key thing is not /everything/ has to be SQL. And SQL databases like Postgres and SQLite can be used for a lot more than SQL now. Also, don’t be afraid to just throw protos/JSON/whatever into a database with no or mininal schema to get going. But manage data design debt ruthlessly, it can haunt you.
My biggest learnings:
Don't prematurely normalize data, but if it is obvious it can always stay normalized, normalize it. Read the normal forms. Learn about indexing and how data is actually being stored on disk. Just knowing about indexes is a huge advantage even today. Understand and know when to use different styles of data storage: row oriented, column oriented, key value, bigtable style (2d key value), document (rare). Pick good systems. Spend more time than you think you should designing your data. The system is often easy if the data is right. Learn ACID and CAP theorem. Learn when and where you can trade on fundamental database principles in your data model for performance or ease of development. Honestly, a lot of this stuff senior engineers at big tech are just expected to know these days, but it still isn't really obvious and not everyone has big tech problems. Still if you know how to solve the problems at scale and you can get out of your own way it is much easier to write smaller systems (most problems people have).
So in terms of resources, go learn about each of those concepts. Read papers. Ask an LLM about them. Play with databases and storage systems. Maybe try to write your own simple database. Go read about how people design massively scaled distributed systems and what systems they use to manage data. Just like with programming languages, be flexible and open minded. Read about how distributed systems work (CAP theorem). Almost all data systems make tradeoffs in that realm to meet cost/performance/implementation goals.
- One of the few things I have used in programming and technology consistently for over 25 years is SQL. Almost no time spent learning how to organize and query data has been a waste in my career.
- Yep. I have Claude snapshot to a markdown doc with key points and resume and iterate. Saves so many tokens.
- A lot of skills in say, running a business, really do transfer. It is possible to gain expertise on how to run a small business and translate that to other realms of running a business. But it is also important, perhaps critical, to recognize limitations. The less similar the situation and environment the less that will transfer. Some times enough transfers that the insights are useful. Some times it is actively harmful to apply previous approaches. Recognizing the differences and what transfers is much harder but also a skill. Becoming skilled enough to help up until your limitations is how you can continuously be successful in domains you have no right to be. The irony is even then you may still not really be able to offer helpful insight.
- Most of us are grossly unqualified to provide opinions on any domain save some hyper specialized domain we invest years of effort into. I always think about that when reading comments on the Internet :)
- There is a very important concept in security engineering around feedback loops. Consider the following: A vulnerability is discovered 5 years after it was introduced. The issue is patched and life goes on for the engineering organization that discovered it. Some time passes and they discover an architectural flaw and that the issue was not isolated. They must now expend precious effort fixing this entire flaw and the 5 years of dependencies that accreted on it. Now, consider, the team that designed this system and the engineer that implemented it discover the vulnerability leading to the architectural issue within two weeks. They refactor the code and eliminated generational security debt. Not to mention the engineers that wrote the code are not around 5 years later further increasing the "interest" on the debt.
I would note you might see this as another bland "shift left" argument and you could definitely view if through this lens. But if you consider it from a systems thinking lens it actually incorporates dynamics that are not typically included in shift left. It helps you consider the system within your organization and how to shorten those feedback loops. It also, conveniently, makes engineering organizations stronger as a whole as these feedback loops are also intrinsically linked to the organizations software development process as a whole. It is pretty hard to have a tight security vulnerability discovery loop without a good software engineering practice around it. For security issues like this they are effectively a strict subset of software quality issues.
You can apply this feedback loop shortening to /so/ many things in life.
- Potentially. I care a lot about this. I think this is a pretty easy case to fight them on 1A grounds as the case law is quite settled and clear per my understanding. So they can have unconstitutional laws on the books, but the long tail of that fight is against the.
- You are of course correct. There are always limits on speech. In this area, however, we have already decided how it works. You cannot regulate what private citizens record in public spaces with no expectation of privacy and you definitely cannot regulate what they do with that data.
- I would blatantly ignore that law. I am in a position to easily fight a state entity with legal resources. They definitely cannot regulate that constitutionally. As a private citizen I am not posting notices. It is bad law that doesn't protect anyone and erodes protected rights.
- It is very janky. The speed camera I have an old Core i5 that is running YOLOv8 on the integrated GPU and it can just /barely/ handle 30FPS of inference. The code is all Python and vibe coded (for science). The speed camera needs a perpendicular view to work best for how I set it up (measuring two reference points with a known distance). So the ALPR camera is separate and I basically just buffer video and built this ultra janky scheme where I call an HTTP endpoint and it saves the last few seconds and then I batch process to associate the plate later in the web app. It is all CSV and plain files; this is a perfect append only DB scenario. Eventually it will need the wonders of the big data format SQLite probably, but I am sure Claude will know what to do ;) The long term solution would be to have a proper radar circuit and two cameras facing both road directions to capture the rear plate as people often don't use front plates here even though they are required to by law.
(the point, though, is you don't need a lot of GPU power to do say YOLOv8 inference on the pre-trained models) and OpenCV makes this all pretty darn easy.
- You are mixing up the duties and rights a government has vs. the duties and rights citizens have. The one area I might start to agree is corporate personhood and giving corporations the same rights as a private citizen in this regard because their interests are very different from a private citizens. The whole point of the constitution is largely what the government can't do to its citizens. The goal is to protect citizens FROM its government by carving out our rights. These of course apply broadly, but I can't, for example, as a private citizen really violate your 4A rights very easily.
- Yes, I agree, but I am saying there are virtually zero grounds to legislate the use case I provided. They try to weasel it on "privacy" grounds and "transparency" when you share the data, but yeah. I agree.
- Unintended consequences. Maybe it can just be annoying and show each car its count of speed 10mph over the limit as they pass
- I feel if you have a camera on your property with a view of public spaces they have a losing argument. I doubt none of that holds water constitutionally. This is first amendment protected. If you are filming a public space with no expectation of privacy the government has no constitutional authority to restrict you if you are retaining the data private and never sharing it.
So far the only legal area that matters is the government itself being regulated in how they use ALPR since they are the entity that can actually infringe upon constitutional rights.
- Interesting. It actually is posted that my property is under video surveillance. Colorado though. It seems like you would have a poor argument that you can’t collect and analyze images of a public space.
One cynical aspect of Colorado law I learned about going down the ALPR rabbit hole: in Colorado it is a higher class misdemeanor than regular traffic violations to purposely obfuscate your plate to interfere with automated plate reading. The law is “well written” in that there is little wiggle room if they could somehow prove your intent. Meanwhile it is a lesser class violation to simply not have a plate at all. Their intent feels pretty clear to me.
- I am the loud exhaust. Where we live the noise pollution is not a concern and I have no complaints around that. Many of my neighbors have lifted trucks and go vroom cars. Ironically the performance cars are the nicest drivers :)
- I started building ALPR and speed detection systems for my house based on RTSP feed. I kind of want to finish this with an outdoor TV that has a leaderboard of the drivers that drive the fastest and their license plate in public display on my property, but visible to the street. In part to make my neighbors aware of how powerful ALPR technology is now, but also many of my neighbors should slow the heck down. I am not sure how popular this would be, but also I kind of like starting the right kind of trouble :)
- I recently started playing with these in game design as well to coordinate networking and game threads in a lock free manner. If it fits your use case it is truly a free lunch! They definitely have a lot of edge cases and are not easy to implement, but they aren't too crazy either.